Create releases for drupal-project

[grasmash]

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?

[webflo]

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.

[feikede]

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).

[gitressa]

This would also be useful if you want to download an older version to test upgrading.

[normanlolx]

Maybe something like DRUPAL-CONCAT.PROJECT.PROJECT?

• 859.0.0
• 859.1.0
• 860.0.0
• 861.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.0
• 85.0.1
• 86.0.0.
• 86.0.1
• 86.0.2
• etc.

[normanlolx]

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.

[normanlolx]

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.

[AlexSkrypnyk]

The requirements for versioning are:

1. Be able to pin-point to a specific change set (kinda what versioning is by definition).
2. Be able to release a patch version
3. 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:

1. CORE_MAJOR.x-MAJOR-MINOR-PATCH => 10.x-1.2.3 - most explicit
2. CORE_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 .x suffix is in alignment with how contribs used to be versioned. But this could be confusing as what 2 and 3 mean - the MAJOR or MINOR?
3. CORE_MAJOR-MAJOR-MINOR-PATCH => 10-1.2 - as above, but without .x since this is not a contrib. Same problems with understanding of the versions still remain.
4. 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.

To me, the most unambiguous format is CORE_MAJOR.x-MAJOR-MINOR-PATCH => 10.x-1.2.3

[normanlolx]

Yeah, I like 10.x-1.2.3, as it also clearly translates to branch-major.minor.patch.