When operating semver branches such as a 2.0.x release and a 2.1.x release the release indicate to use “composer require drupal/module:^2.n” where N is the minor value.
Technically the commands are not incorrect, however using the command to install the 2.0 release will actually result in the 2.1 release being installed.
For most modules this likely is not a significant issue, and upgrading to the new minor is likely what most users want, however it has a chance to be confusing when you just copy the command into the console thinking “oh I want the older branch” not thinking the command isn’t tied to just the minor release.
Create a 2.0.x-dev release branch and a 2.1.x-dev release branch. Release a point release for each.
TBD
I’m honestly not sure the best option here. Possible solutions I can see are:
TBD
TBD
None Expected.
None Expected.
| Comment | File | Size | Author |
|---|---|---|---|
| FAE00732-BC8F-4D31-923D-A76CA70E2A4B.jpeg | 468.17 KB | cmlara |
Comments
Comment #2
avpadernoComment #3
hestenetI'm inclined to think that the right answer is:
Because with the other options, people may not realize they actually pinned their requirement to a minor version. That is potentially more risky than winding up with a minor further ahead than you expected, because pinning a version could cause you to miss a security release.
Hmmm...
Comment #4
cmlaraIts a complex one for sure with no perfect answer.
I will note that it is my understanding that once the maintainer marks the 2.0.x branch unsupported it does trigger alerts in upgrade status, so we do have that as a mitigating factor, though that does not help those who have upgrade status disabled.
I would expect the maintainer should so long as the branch exists as supported be publishing security fixes for it (especially for security covered modules) and not just to the latest major.
I'm sure most developers won't use releases on D.O. this way, and I haven't yet moved any of my projects up into semver enough to actually do so, but I always imagined scenarios where if the project warranted it (features are disruptive, or stability is critical) where I may be "rapidly" incrementing the Minor version, but I have one minor every so often that gets some standard limited policy to it (critical bugfixes, security only, etc) Essentially LTS releases.
I won't object if its left to the administrator. I just felt this at least needed a review so we all knew it is occurring and we intentionally accept it as intended process.
Comment #5
hestenetThat's very thoughtfully put.
I think we probably will land on leaving it to the administrator, but I think I'll leave this open for the next day or two, in case we have another good idea.
Comment #6
avpadernoWhat would happen when a user runs
composer require drupal/module:^2.0on Drupal 9.1?I understand the reasons for doing so, but isn't getting release 2.1.0 when using
composer require drupal/module:^2.0different to what obtained with other Composer packages?Comment #7
cmlaraIt will depend upon the modules defined limits. In the case of the photo I posted for Honeypot it would end up with 2.0.2 because 2.1.0 has a constraint of at least D9.2 that will not be met.
I'm not sure I understand the questions bout being different with other composer packages.
Comment #8
avpadernoWhat happens when
composer require symfony/symfony ^5.3.11is used for a non-Drupal project? Would I get Symfony 5.4.0 because that is supported, or would I get the version I required?In other words, is
composer require drupal/module:^2.0giving a version that a user used to run Composer isn't expecting?Would the administrator be able to understand the consequences of giving a 2.1 release instead of a 2.0 release, considering there could be some differences as for dependencies or requirements?
Comment #9
mmjvb commentedRecommend using require without version getting composer to decide what the version constraint is going to be. Site builders would get a decent constraint and the most recent. Possibly conflicting with other constraints, which should provide information on the version to require.
With composer require symfony/symfony ^5.3.11 you never know what you get:
- use --no-update to get the constraint in
- use --dry-run to see what version your requirements resolve to
By default it will get you the most recent in 5, meaning the semantic highest version of 5, not last released!
composer require drupal/module:^2.0 will give you the semantic highest version considering other requirements. The version constraint will be ^2.0 allowing for 2.0.*
This should not be something a Composer user to be surprised about, might surprise Drupal users coming from the project page. They would be lured into thinking they would get anything 2.0 while getting 2.3.5, not even on the page! (2.3.5 currently not released, just to make the point)
So, use composer require drupal/module and have Composer determine the constraint and get the most recent according to project requirements or Problems reported for not being able to resolve them.