Magento-lts: How should we do release version numbers?

[drobinson]

In the past Magento didn't really follow a helpful versioning pattern (see readme). However, lately they are sticking to patch level version increases, so we should revisit how we do our branching and release tagging for this repo. Any thoughts/suggestions?

[colinmollenhour]

Here is my idea for versioning to be completely composer compatible while still tracking official releases and allowing for our own releases independent of official releases. It's a little creative but not to hard to understand hopefully.

1. Drop the 1. Composer/SemVer only supports three numbers in a version and there will never be a "2." from this repo.
2. Tag the current version as 9.30.0. The "30" is the "y.z" from the official version. Each new official patch would increment our "X", so the next official release would either be tagged as 9.31.0 or 9.40.0.
3. To remain semver compatible a hypothetical 1.10.0.0 release would have to be tagged as "10.0.0" instead of "10.00.0".
4. Create a new branch for each official minor release (not ".z" patches), e.g. "9.3x" which is the new master. Older versions can be represented by 9.2x and 8.1x.
5. Tag future non-official versions as 9.30.*. These would be tagged whenever someone feels there is a need I suppose, perhaps even after every PR merge.
6. When a new "y" or "z" official version is released then our "x" would be changed accordingly (e.g. "9.40.0" for "1.9.4.0". Unless the official versions get into double digits this should be safe. E.g. if there was _both_ a 1.10.1.10 and 1.10.11.0 there would be problems. I think this risk is very low.
7. New features will always be merged with the latest default branch (e.g. "9.3x"). That is, once 9.40.0 is released there will not be a new 9.3X.X unless someone really needs to backport a feature or fix and then they can submit a PR to the older "9.3x" branch.
8. When a new official minor version is released always tag the old default branch with a new ".Z" before incrementing the ".Y". E.g. when 1.9.4.0 is released the HEAD of 9.3x would get tagged and a new branch 9.4x created before 9.40.0 is tagged.

[infabo]

+1 @colinmollenhour

[colinmollenhour]

After merging several branches and looking at older ones that can be merged into their originally based branches I think the fewer the branches we have the better.. Maybe going to "9.xx" vs "9.3x" would be worthwhile (while still using the same proposed tagging scheme). The effect would be that between 1.9.3.x and 1.9.4.0 any in progress PRs would be merged into the latest version instead of an older version. The good thing about this is that it puts the onus on the committer to rebase if upstream commits cause conflicts rather than on a maintainer to do a second merge afterward. Also it would be really easy to click "Merge" and forget that the PR was merged in an old branch and not the newest branch and while the PR would be closed the code would get left behind in an old branch.

[drobinson]

This sounds pretty good, but my main apprehension is the cognitive load this would place on users of this repo for translating which "version" they should be using. I've been using the 4-deep version numbers in my composer.json since I started using this repo and it seems to work, so it's surprising to me that it's not supported.

[drobinson]

@colinmollenhour @LeeSaferite If you guys don't have any opinion otherwise, I'll create the "1.9.3x" branch today.

[LeeSaferite]

My opinion is that the branch should be 1.9.3.x and we tag releases. Composer runs off the tags amd if you use -dev it'll use branches instead.

[drobinson]

We do have the issue now, that unless we want to have moving tags, someone can't expect to have bug fixes/etc if we tag 1.9.3.2 right now on the 1.9.3.x branch.

[colinmollenhour]

@drobinson No objection.

[drobinson]

@colinmollenhour no objection to moving tags?

[colinmollenhour]

No, I was referring to:

If you guys don't have any opinion otherwise, I'll create the "1.9.3x" branch today.

I do object to updating tags as tags are widely assumed to be immutable and it is not worth breaking that convention.