For a composer version constraint how stable is the "patch" Composer versions in terms of the order in the stability-flags.
Is it stable? Where does it fit into the order?
The minimum-stability setting does not list it:
Available options (in order of stability) are dev, alpha, beta, RC, and stable.
From common sense I would say that a patch is a patched stable version so I would consider it stable.
But would a version requirement of 3.1.3-patch1 satisfy a minimum-stability-Setting of stable?
Patch is considered stable. Take a look at the code in VersionSelectorTest.php:
// real version, is dev package, stability, expected recommendation, [branch-alias]
array('3.1.2-patch', false, 'stable', '^3.1')
Related
I was taking a look at https://gcc.gnu.org/releases.html and saw that the GCC version numbers aren't increasing monotonically with respect to the date unlike most products where the most recent version has the largest version number.
e.g., GCC 8.5 was released 5/14/21, and 11.1 4/27/21.
Why are the version numbers for gcc structured this way?
Based on reading how they format their version numbers, it seems like its because each major release ends up as a branch with their own number of fixes rather then features. There may be reasons on why you would want to stay on the 8.x branch rather then 11.x branch due to compatibility issues, which is why they release fixes for older branches. You can read more here. Hopes this helps clear things up!
I have a utility service x which is in maven repo and is used by some of my other services. We normally update the minor version of the service x when we make small changes and we are currently on version 1.0.15.
No I am making another change and I was thinking whether I should update version to 1.0.16 or I should update the version like 1.1.0.
If anyone can provide an explanation on how this should be done in general, that would I am sure help other developers as well as me. Please let me know if you need further information.
Different projects follow different standards on this, so follow what the repository has done to date.
A well-regarded standard for this is called Semantic Versioning (https://semver.org/). If you are starting a new project or there isn't a standard already in place, I would recommend using this.
Semantic Versions are in the format: MAJOR.MINOR.PATCH.
If you have fixed a bug: increase the patch version
If you have introduced new functionality in a non-breaking way: increase the minor version (and reset patch to 0)
If you have introduced breaking changes: increase the major version (and reset the patch and minor version to 0).
If you are unsure whether your change is a breaking change or not - consider your package (or API) from its consumers' perspectives. If their code has to change as a result of your change then it's a breaking change.
I'm using Yarn and when I installed my packages, I wanted to update them. I am really new to this so I having trouble understand what each one meaning.
An explanation would be helpful as I am not getting it from Googling.
(I am using this to install and working with SPFx).
yarn outdated v1.17.3 outdated
info Color legend :
"<red>" : Major Update backward-incompatible updates
"<yellow>" : Minor Update backward-compatible features
"<green>" : Patch Update backward-compatible bug fixes
Edit: - Finally think I understand..
red = Major Update. The updates are NOT backward-compatible.
yellow = Minor Update. The updates have backward-compatible features.
green = Patch Update. The updates are just patches to fix bugs, and are backward-compatible.
Please correct if wrong.
You are quite correct. NPM packages use Semver (Semantic Versioning) to indicate a package version. The version number isn't merely just an incremented number, it tells you a bit about what happened with an upgrade.
So you will most of the time have a version numbers that look like 1.2.3 or (MAJOR.MINOR.PATCH), where:
MAJOR - Big changes that changes the way the package is used, so you might need to update how you use/call the corresponding package. The update is thus not backward compatible.
MINOR - New functionality was added to the corresponding package, your code doesn't have to change. The change is backward compatible.
PATCH - No features were added, patches normally include bug fixes or small optimisations to a package.
Sometimes there is more meta data in the version number, for example 1.0.0-rc.1
indicates that this is a Release Candidate. Other examples include 1.0.0-alpha or 1.0.0-beta.
You can read more on Semantic Versioning at https://semver.org/
I would like to know, if e.g. 0.1.0 is already stable concerning a composer install.
I am familar with the SemVer Tags and I know, that the API can change with every realease which is not the first major (1.0.0) but still: the tag is a fixed state of the project.
So, will composer consider such a tag as stable or not?
From a semantic versioning perspective, it is not stable. However, Composer will treat (almost) all tags as having stability "stable".
Good to know: the ^ operator behaves very similarly to the ~ operator but it sticks closer to semantic versioning, and will always allow non-breaking updates. For example ^1.2.3 is equivalent to >=1.2.3 <2.0.0 as none of the releases until 2.0 should break backwards compatibility. For pre-1.0 versions it also acts with safety in mind and treats ^0.3 as >=0.3.0 <0.4.0.
For more information, see https://getcomposer.org/doc/articles/versions.md
I already have the geoip2 package installed. When I installed it some time ago, it required guzzle 3.* so it installed guzzle 3.9.1 as one of its dependencies.
Now I want to install the predicitonio package, so I added it to my composer.json
"require": {
...
...
"geoip2/geoip2": "0.6.*",
"predictionio/predictionio": "~0.7.1"
}
The issue is predictionio requires guzzle 3.8.0 or 3.8.1, it won't accept the already installed 3.9.1 version.
I believe guzzle 3.8.0 would satisfy both geoip2 and predictionio, so the question is how can I downgrade guzzle, keeping in mind guzzle doesn't appear in my composer.json, only the composer.lock.
Below is the output when I run composer update predictionio/predictionio
Problem 1
- Installation request for predictionio/predictionio ~0.7.1 -> satisfiable by predictionio/predictionio[v0.7.1].
- Conclusion: remove guzzle/guzzle v3.9.1
- predictionio/predictionio v0.7.1 requires guzzle/guzzle ~3.8.0 -> satisfiable by guzzle/guzzle[v3.8.0, v3.8.1].
- Can only install one of: guzzle/guzzle[v3.9.1, v3.8.0].
- Can only install one of: guzzle/guzzle[v3.9.1, v3.8.1].
- Installation request for guzzle/guzzle == 3.9.1.0 -> satisfiable by guzzle/guzzle[v3.9.1].
You don't need to add Guzzle to your composer.json. All you have to do is updating Guzzle when you add the new package. (this will downgrade Guzzle to match PredictionIO's requirements)
Simply run
composer update predictionio/predictionio guzzle/guzzle
As you can see, you can provide multiple packages to composer update by separating them with a space. This is described in the documentation.
Some hints related to the question:
By running composer update named/package, you only allow this package to be added or it's version increased, but nothing else. The same (but only adding stuff) will happen with composer require named/package:~1.0 (this is a nice way to add stuff without having to mess with the json formatting).
The most simple solution when updating stuff is to only run composer update. Without a package name, ALL packages may be updated.
Updating everything might be a bit risky if you weren't careful with selecting your software packages. Personally I recommend using software that somehow seems to use semantic versioning, which very nicely allows to use the tilde version requirement in Composer. I'd say that everyone should try to use ~X.Y as the version description, because this allows for both patches as well as compatible updates to be installed.
Libraries you use should allow for enough loosely defined versions of THEIR dependencies. In your example, the predictionio/predictionio package requires guzzle/guzzle:~3.8.0 - they probably have reasons to do so, but in turn force everyone that tries to use their software to use Guzzle 3.8.0 or 3.8.1. I doubt the Guzzle maintainers will break backwards compatibility, because they know they create a very important, basic piece of software that is expected to work, and I think they will receive bug reports pretty soon should they break stuff nonetheless. I would very much like to see the dependencies of any library to allow for compatible updates without restriction, i.e. in this case ~3.8 would be much better.
Avoid depending on branches at all cost. If it is unavoidable to use a branch, assign it an alias version number: require: { "named/package": "dev-master as 1.2.2" } If no proper version number can be guessed from earlier releases, start with 0.0.0. That way you can switch to a released version later, which will integrate better into the rest of the version numbers.
If you want to install a specific version of a package, you can simply add this to your composer.json in the require section:
"guzzle/guzzle" : "3.8.0",
And then
composer update guzzle/guzzle