Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.We have discussed switching to semantic versionning in the past, to get rid of the weird "oh aegir x.y is just alpha" ghost we keep on carrying around.
We have had 13 alpha/beta/rc releases in the 1.x release cycle, and again 10 such release in the 2.x release cycle. Those were silly, and blocked adoption.
We are thinking of releasing 3.0.0 as is, right now, as an "alpha" release (just *say* it's alpha in the release notes!) and quickly make a 3.0.1 with the bugfixes as necessary.
We are also thinking of releasing the 2.x branch using semantic versionning, so 2.0 becomes 2.0.0.
Comments
Comment #1
anarcat CreditAttribution: anarcat commentedThose are the pages to update:
http://community.aegirproject.org/content/branch-and-tagging-conventions
http://community.aegirproject.org/node/32
Comment #2
helmo CreditAttribution: helmo commentedI'm not entirely convinced this is worth the effort...
For Drush/provision modules I do see a small advantage, but less for hosting.
How would we handle this on Drupal.org with releases? Or do we tell everyone to just get it from a git tag?
I don't mind semantic versioning, but would hate to lose the ability to tie issues to a version.
Comment #3
anarcat CreditAttribution: anarcat commentedI don't see how semantic versionning would keep us from doing regular releases here... What am I missing?
Comment #4
anarcat CreditAttribution: anarcat commentedOh I see - the release scripts just block us completely from making actual tarballs.
Well that's a pain.
Comment #5
helmo CreditAttribution: helmo commentedI would support an issue to make drupal.org releases semantic versioning friendly ... Would be nice to get Drush back on D.o aswel.
Comment #6
anarcat CreditAttribution: anarcat commentedso I made a few comments on that epic thread, but I don't expect this to be resolved any time soon, unless we actually start hacking at d.o infrastructure ourselves. it may be easier for us to just migrate off to github or something, unfortunately. marking this as postponed to 3.x
Comment #7
ergonlogicI posted #2189131: Update DrupalorgVersioncontrolLabelVersionMapperGit for semantic versioning in contrib against the the drupalorg project to hopefully help get this moving.
Comment #8
helmo CreditAttribution: helmo as a volunteer and at Initfour websolutions for Aegir Cooperative commentedminor update on this. Jon created a 3.111 version of tasks extra
Comment #9
Jon PughYep, it worked well. Learned the technique from OpenAtrium. You can put the "real version", (currently 3.11.1) in the release title, and in a release description that shows up on the project page.
Update system considers the latest release based on date.
I think we should really consider doing this now. There's nothing stopping us from tagging 3.12.0 as 7.x-3.120
Comment #10
Jon PughWould like some feedback on releasing the next version as
3.12.0as tag7.x-3.120OpenAtrium has been using semantically versioned releases on drupal.org since Jan 2015: https://www.drupal.org/project/openatrium/releases/7.x-2.30-rc1
Thoughts on switching now to 3.12.0? This will allow us to do patch releases for drupal core and contrib if needed.
Comment #11
helmo CreditAttribution: helmo as a volunteer and at Initfour websolutions for Aegir Cooperative commentedI'm eager to try it ... but with a few reservations
- The release scripts might have to be adapted a bit
- I don't want to delay the release again
- Doing a release takes considerable time, so doing more release would need more volunteers or funding.
Comment #12
helmo CreditAttribution: helmo as a volunteer and at Initfour websolutions for Aegir Cooperative commentedSeems to work out :)
https://www.drupal.org/project/hostmaster/releases/7.x-3.120
Comment #13
helmo CreditAttribution: helmo as a volunteer and at Initfour websolutions for Aegir Cooperative commentedComment #14
Jon Pughhttps://www.drupal.org/node/2882434