Branch cleaning and renaming

[fballiano]

Hi everybody,
I think it would be time for some cleaning in our branch department.

• I noticed that some old releases (1.9.2.0, 1.9.2.1, 1.9.2.2, 1.9.2.3) were not "tagged" but we still had the stale branches, so I converted those branches into tags and removed the branches
• I can't convert branches 1.9.2.4, 1.9.3.0, 1.9.3.1 into a tags since they're "protected" (EDIT: these branches have been unlocked and converted to tags too)
• I also think branch 1.9.3.x should be deleted, since it's no longer maintained and it could only create confusion (again, I can't do that since it's a protected branch, a maintainer with higher privileges should do that)
• IMHO "feature" branches shouldn't be on our main repo (feature/init-orig-data-collection-load, sreichel-fix-creditmemo-tax and functional-test-suite) @Sekiphp, @sreichel @akrzemianowski could you move those to your personal forks and create PRs?

I also believe it would be time for renaming branch 1.9.4.x to v19 and 20.0 to v20 (and maybe set v20 as default, since it's out most advanced effort), it would be more consistent with our version naming and we'd finally detach ourselves from the M1 1.9.x.x era which is loooong gone now.

I'm tagging some of the maintainers since I think we need them in this thread :-)
@tmotyl, @Flyingmana, @colinmollenhour, @sreichel

[tmotyl]

I'm ok with these changes, however:

1. please keep in mind that people have branch names in their CI/CD setups, so impact has to be considered if changing a name is not backward compatible. And communication needs to be prepared.

2. The biggest pain I have with current branch scheme is around branches with version 20
   Up until previous release we've built our releases on top of 20.0.x-dev branch. In our pipelines we were adding few commits on top of this branch (some our PR"s are not merged yet), and built production releases from it.
   This allowed us to always have the most recent v20, without waiting for the tagged release. The benefit for the openmage is that we could report issues in v20 before the new tag was release -> which is super helpful for the project!

Now I suppose that branch 20.0 has become what branch 20.0.x-dev was in the past. But there is no communication. Even on packagist branch 20.0 is not there.
And judging from the packagist stats people still use 20.0.x-dev branch in their CI CD setup -> meaning they don't benefit from recent release and patches.
https://packagist.org/packages/openmage/magento-lts/stats#20.0.x-dev

3. we should encourage people to use v20, but our communication is focused right now on 1.9 -> see e.g. readme - no information how to use 20 there. Right now the v20 is treated as second-class citizen.

4. Branch with v20 should be updated on every commit to branch 1.9/19 - to make it usable.

Summing up. In my opinion the most important thing is to make version 20 first class citizen, before we do some cleaning with old branches, by:

• documentation
• packagist
• communication which branch to use and how
• updating 20 branch more often

[Flyingmana]

regarding the 20.0.x-dev branch, I dont know(anymore) which was first, and who started the other one. I use 20.0.x because its analog in naming.

Possible 20.0.x-dev was created later by someone, because composer did not automatically transform the -dev reference to this branch? Because normally the branches are referenced in composer by using branchname-dev, at least in the past

[Flyingmana]

Iam not a fan of deleting old branches, because not-maintained does not equal not used. And generally whoever finds themselve to need a PR there, we are not declining it automatically if they need it on this branch.
Although this is more a general decision and more relevant, when we regularly fade out old versions.

[fballiano]

If someone really needs to write a patch on 1.8 we can convert the tag back to a branch, patch, release, archive the branch again, easy peasy ;-)

[Flyingmana]

was more meant about the 1.9.3.x, or also the 20.0.x (when we discontinue it at one point after a new released version)

[fballiano]

mmmm I see, anyway I wouldn't facilitate the use obsolete, vulnerable and out of life software. They could stil run it and write patches for that but having them here... to me it's a no no :-)

We're anyway talking about branches that were last touched 6 years ago :-)

[fballiano]

can we remove the release-20.0 and release-19.4.x? we created those right before previous release right? so shouldn't be used by anybody right?

[addison74]

I agree with the deletion of all branches and only the two remaining, provided that what is deleted is checked to see if it needs to be transferred or not. As a personal opinion when I make a fork from OM I don't like to receive all those old branches. I would appreciate it to be only two.

Related to 1 or 2 future versions. I think for a while we can stay as we are. To change the name of the branches that I don't like what 1.9.4.x or 20.x looks like either, two branches can be created and from now on all PR's will go there. The rest remain the same until they are merged or closed. Obviously more attention will be needed, but fresh air must be brought into this project.

I can't help but appreciate that the idea of more active collaborations has led to a decrease in the number of PR's by almost two and a half times and of the reported issues by half, in almost 2 months. Magento 2 still has over 1000 issues and the same unintegrated PR's. I don't like projects where something like this happens.

It remains to agree with what you want to do in this regard.

[colinmollenhour]

Agreed there should be only a few branches, no strong opinion what they should be named or how they are used so will defer to others.

Iam not a fan of deleting old branches, because not-maintained does not equal not used.

If anyone is using the very old branches deleting them might break some CI/CD step but shouldn't break a production instance, for example a "git pull" will just fail but won't delete any files.
If someone wants these branches they could always maintain them as a private fork but honestly there are so many changes that would create conflicts (e.g. vardocs) that I don't see us ever backporting fixes to these old branches and their presence sorta implies they are maintained which is a false assumption we don't want people to have. If they are deleted then everyone will know they need to change to a different branch to be "safe".

One suggestion is that we need a clear direction on where PRs should be based.. Maybe I missed it. :) Do we based them on the oldest maintained branch and port them up to the latest or base them on the newest and then backport to older branches? I think the latter makes the most sense. Just let me know what branch name to use and I'll happily update my PRs.

@fballiano FYI I unprotected the branches listed in your second bullet point.

[fballiano]

If someone wants these branches they could always maintain them as a private fork

They could checkout the tag instead of the branch, it's maybe a minute fix :-)

One suggestion is that we need a clear direction on where PRs should be based.. Maybe I missed it. :) Do we based them on the oldest maintained branch and port them up to the latest or base them on the newest and then backport to older branches? I think the latter makes the most sense. Just let me know what branch name to use and I'll happily update my PRs.

I also think we should switch the default branch to v20, so that new PRs would be based on that branch and later backported to v19. I'm 100% for this idea.

@fballiano FYI I unprotected the branches listed in your second bullet point.

thanks!

[addison74]

I agree for making v20 the default branch.

I strongly support new branches names based on this format openmage-.... and openmage-.... No more number like 19 or 20. It could be openmage (for v20) and openmage-bc (v19 for backward compatibility).

[fballiano]

mmm that's an idea but it's tricky, I woulnd't go back with version numbers and I'd prefer (at this stage) to keep the v19 and v20 naming (although we may try to bump the v20 name to v22? like the current year? dunno it that makes sense)