Create releases for drupal-project
Opened this issue · 23 comments
I'd like to post the following instructions on the /download page on Drupal.org:
composer create-project drupal-composer/drupal-project --stability dev --no-interaction
However, I'd prefer that it require a stable tag for drupal-project rather than asking users to rely on a dev dependency. It seems to be setting a bad example.
Would you be willing to begin cutting tags for drupal-project?
Not relying on dev dependencies is a good thing, and i thought about a tagging releases in the fast. But i had trouble finding the a proper version scheme, that fits. Packagist would show the version of the template not necessarily the version of Drupal core. This mighty be confusing for some users.
Is it possible, to tag this repository (the composer-repo) with the drupal core version? I am building docker containers from your drupal-project (https://hub.docker.com/r/feikede/drupal8-docker/), thanks, but unfortunately it's not possible to have reliable release tags on the containers with a general 8.x-dev tag here (or I need to patch the deps in your composer.json).
This would also be useful if you want to download an older version to test upgrading.
Maybe something like DRUPAL-CONCAT.PROJECT.PROJECT?
859.0.0859.1.0860.0.0861.0.0- etc.
Although that would mean much more tagging. And probably fixating the Drupal version in the composer.json. Bad.
Then maybe DRUPAL-MAJOR-MINOR-CONCAT.ZERO.PROJECT?
85.0.085.0.186.0.0.86.0.186.0.2- etc.
Or would fixating the Drupal version for every release be a desired thing?
This would also be useful if you want to download an older version to test upgrading.
On the other hand. Starting with just 1.0.0 should be fine for drupal-project, no? Confusion with Drupal versions should be minimal as long as drupal-project doesn't make big jumps too fast.
The requirements for versioning are:
- Be able to pin-point to a specific change set (kinda what versioning is by definition).
- Be able to release a patch version
- Be able to distinguish what major version of Drupal the release applies to.
Note that using DRUPAL-CONCAT is not needed as we are not supporting per-core patch releases in this project - we want to be able to release independently of the core realeases.
Format candidates:
CORE_MAJOR.x-MAJOR-MINOR-PATCH=>10.x-1.2.3- most explicitCORE_MAJOR.x-MINOR-PATCH=>10.x-2.3- this project already has a branch per core, so using core version as major unifies this. Using.xsuffix is in alignment with how contribs used to be versioned. But this could be confusing as what2and3mean - theMAJORorMINOR?CORE_MAJOR-MAJOR-MINOR-PATCH=>10-1.2- as above, but without.xsince this is not a contrib. Same problems with understanding of the versions still remain.CORE_MAJOR-MINOR-PATCH->10.1.2- core version IS the major version of this repo. This may be confusing for some users as they may think that1.2are theMINORandPATCHof core.
To me, the most unambiguous format is CORE_MAJOR.x-MAJOR-MINOR-PATCH => 10.x-1.2.3
Yeah, I like 10.x-1.2.3, as it also clearly translates to branch-major.minor.patch.
@leymannx
what would be the very first release version?
I suggest tagging as 10.x-1.0.0 and 11.x-1.0.0 (once we have a full feature set, of course).
Alternatively, we can start from minor: 10.x-0.1.0 and 11.x-0.1.0
Tagging is good, but the version number should be SemVer compliant. Otherwise it will not appear on Packagist and therefore cannot be used with ‘composer create-project’.
@webflo – Ah I tried this https://jubianchi.github.io/semver-check/#/version/10.x-1.0.0 and it said "green" but I guess that's a false positive.
@AlexSkrypnyk – I also prefer SemVer and if 10.x-1.0.0 is not SemVer compliant we should find something else. 🤔
The other alternative is to follow Drupal core - option 4 from the list bove
CORE_MAJOR-MINOR-PATCH -> 10.1.2 - core version IS the major version of this repo. This may be confusing for some users as they may think that 1.2 are the MINOR and PATCH of core.
What about some strange major version something like 1010 or 10010 (and 1008, 1009, 10011 etc.)?
Some numeric pattern that reflects 10.x-10 how could that look like?
Something that avoids the confusion that we follow core.
https://github.com/webflo/drupal-project-test has tag "10.x-1.0.0" and it does not work on packagist https://packagist.org/packages/webflo/drupal-project-test
Make this repo the dev repo and package it up or sync it to another repo when you do a release.
This doesn't help with the version naming.
The recommended template also has no releases, right?
Linking SemVer definition https://semver.org/#backusnaur-form-grammar-for-valid-semver-versions
Since Packagist is out of our control and it only allows SemVer, we can only solve this within SemVer format.
They are saying that it is "strongly encouraged", but practically, based on the tests done above, it looks like they do not support anything more complex.
Looking at what has been proposed in this thread, to me, CORE_MAJOR.MINOR.PATCH -> 10.1.2, looks like the easiest to use and to maintain.
We can add a line to README.md that release versioning follows Drupal core major version. At the end of the day, this project depends on Drupal core.
I've created this question in Packagist repo (feel free to jump in there to explain things better) composer/packagist#1451
SemVer build metadata works on Packagist. https://packagist.org/packages/webflo/drupal-project-test#11+1.0.0
We could try use use [CORE-MAJOR]+[OUR-Version-Number].
@webflo
I like the idea and have nothing agains a plus in the version. But.
This actually turns our version into build metadata, making it ignored when determining versions precedence. This may have other side effects that depend on a specific implementation of the spec by Packagist.org
https://semver.org/#spec-item-10
