I've been trying to use gitVersion to increment a project to version 1.0.0 after some time of incrementing minor and patch versions.
When using +semver: major the minor version is incremented. for example, version 0.1.1 got incremented to 0.2.0.
In the official documentation it says the following:
One thing to be aware of: If the current version is an alpha-version
(i.e. 0.x.y.), attempting to bump the major version will merely bump
the minor (eg from 0.2.0 to 0.3.0 instead of 1.0.0). Once the current
version is greater than 1.0.0, bumping the major version works as
expected.
I am currently not using a custom configuration file and I was wondering if it is possible to increment the version to 1.0.0 without adding one.
As documented
If you are using next-version and are experiencing weird versioning behaviour, please remove it, create a git tag with an appropriate version number on an appropriate historical commit and see if that resolves any versioning issues you may have
You can set a new version tag like
git tag -a v1.0.0 -m "v1.0.0" on the repository,
gitversion will calculate semVer from the V1.0.0
git tag -a v1.0.0 -m "v1.0.0"
Related
My current understanding is that stable releases are subsets of nightly (essentially with every feature flag turned off), given this is there a way to get the corresponding nightly release for a stable release?
Specifically would rustc 1.62.0-nightly (without any feature flags) have identical behavior to rustc 1.62.0?
Stable releases do not use the same code as nightly ones. Nightly releases are built off of the master branch, whereas stable releases have their own branch off of nightly with fixes backported. See also the page for how Rust's Git branching works.
The version subcommand or --version argument to most rust tools (cargo, rustc, etc) should print the git hash along with the version info, which will tell you exactly what version of the source it was built against. Additionally, stable releases are tagged in the Git repo.
I'm supporting a project that has a version of the following package.
https://www.npmjs.com/package/vue-typeahead-bootstrap
the version in the package.json says we imported version 2.6.0 however the lastest version currently is 2.5.3 beta. I would have to assume someone manually changed this. So if the version specified is beyond the version that currently exists, is it smart enough to just take the latest version. and will it automatically update the the newest version until it hits 2.6.0?
I'm gonna just change it match the current version anyway, but I was curious if anyone knew the functionality of this.
Please look at versions of this package
The version 2.6.0 goes prior 2.5.x versions
I have freetype2 installed on my system but I am also trying to install it from source, as well.
My installed version is here: /usr/lib64/pkgconfig/freetype2.pc. That file is listed as version 20.0.14.
To compile another tool, namely fontconfig, I need freetype2 >= 21.0.15.
So I downloaded freetype2 from its source git repo.
The trouble I'm having is that repository doesn't list any version even close to 21.0.15+. All of the tags in that repository are listed as VER-2-6-2, VER-2-9, VER-2-9-1, etc. And the generated freetype.pc file which is created after compilation are also listed as 2.6.2, 2.9, 2.9.1, etc. The version number is not 21.0.15 or even 20.0.14, which my CentOS 7.6 already has.
What determines the listed version in the freetype.pc file? Where can I find the version of freetype that will create a .pc file of >= 21.0.15+? Any clarification would be greatly appreciated.
Apparently the reason is because I was building freetype using CMake. And in the CMakeLists.txt, it's defining a version based on the version of freetype.
# . `CMakeLists.txt' is provided as-is since it is normally not used by the
# developer team.
So it's unsupported. That's why the version number doesn't match.
In reality, the version number actually comes from libtool. See this table. e.g. I was building 2.10.0 freetype, so the freetype.pc should have been written with a version of 23.0.17
And if you build using configure, instead of cmake, you can find that exact same version 23.0.17 listed as "23:0:17" in the builds/unix/configure.raw file.
I was trying to build a Yocto Image for intel processor.
I downloaded the latest source code of poky and then clone the meta-intel branch and added it to bblayers.conf file.
git clone git://git.yoctoproject.org/meta-intel
MACHINE = "intel-core2-32"
I started build with the following command
bitbake core-image-sato
And got the following error:
configure: error: Package requirements (libva >= 1.1.0) were not met:
|
| Requested 'libva >= 1.1.0' but version of libva is 0.40.0
|
| Consider adjusting the PKG_CONFIG_PATH environment variable if you
| installed software in a non-standard prefix.
|
I have the following recipe in this folder meta/recipes-graphics/libva/libva_1.8.3.bb
It means the version should be 1.8.3 instead of 0.4.0
The version of libva that configure is looking for (in some recipe you didn't name) is the API version. This is not necessarily the same as the package version. libva is one of the examples where package/recipe version and API version are not too related.
libva 1.x provides API version 0.y . Yes, it's weird.
Your real problem is here:
I downloaded the latest source code of poky and then clone the
meta-intel branch
meta-intel is not a branch, it's a layer and git repo. If you did not specifically change the branch of that git repo, you are using master. This is typically not compatible with release versions of poky.
If you want to keep using the poky release you've downloaded, you must checkout the matching release branch/tag in meta-intel.
This is not required to fix your issue but I would suggest using git to get all of your layers, poky included. That way it's easy to pick the branches you want (and the method to do that is the same for all layers) and also easier to upgrade when e.g. there's a bug fix release to poky...
I need to update PHPMailer on few servers if any old version was installed.
How to check installed version
How to update it to PHPMailer 5.2.20 (for example)
It depends on how you installed it. If you're using the recommended method of using composer, then a simple composer update will get you the latest version. Your composer.lock file will show you which version you currently have, or you can open the VERSION file which will show you the version number you've got - or if you have a very old version that predates the VERSION file, look in the source files instead - they will also say what version they are. If you've installed it manually, just download the latest version from Github and replace your current version.