New branching rules (2023) for OpenMage's main repo

[fballiano]

Maintaining the past is important, but more important is creating the future.

All the details in the document.

[addison74]

I agree. I have not evaluated the impact that changing the name of the branches will have, but everyone will have to make the changes themselves.

• I would change main to openmage.

• I would change v19 to openmage-bc, which would create the connection with backward compatibility.

• No more branches should be added to the project by those who have permissions. Some PRs have branches created directly in OM repository, not in the authors' repositories. It would be natural when I clone the repository to get only 2 branches, not 2 + others.

[justinbeaty]

Previous discussions at OpenMage/magento-lts#2327.

You know that I support this change. Personally if I was on OpenMage v19, I'd probably want less changes per release, and only security fixes and major bug fixes. That seems to be the definition of LTS to me.

[fballiano]

I'd keep "main" as a proposed name because it's the de-facto standard for all projects, it's what "master" was until some years ago.

[Flyingmana]

-1 from me to make 20.0 the main branch as long as the amount of bug fixes and changes merged for v19 is still above 10% of all PRs

[Flyingmana]

Iam also against

5. Forbid maintainers and contributos (whoever can write to the magento-lts repository) from creating new branches, the only allowed branches should be v19, main and all the actively maintained branches that correspond to released version (eg: next year we free v20 to its own branch and main represents v21) and remove all the branches that do not comply with this rule.

because this prevents the option to have a shared feature development happen on the project, and moves it to the single person who creates a draft PR

[addison74]

@Flyingmana - I did not consider this option, but it must be done only by a maintainer with a specific purpose.

[Flyingmana]

@Flyingmana - I did not consider this option, but it must be done only by a maintainer with a specific purpose.

yeah, I did this for a few things, but they got deleted by now it seems

[fballiano]

Iam also against

5. Forbid maintainers and contributos (whoever can write to the magento-lts repository) from creating new branches, the only allowed branches should be v19, main and all the actively maintained branches that correspond to released version (eg: next year we free v20 to its own branch and main represents v21) and remove all the branches that do not comply with this rule.

because this prevents the option to have a shared feature development happen on the project, and moves it to the single person who creates a draft PR

We coauthor PR on daily basis without creating new branches, it can be done and it's much more cleaner (one developer opens a PR maybe marking it as draft just in case, everybody can add commits to that and checkout it without problems).
Although point #5 was more intended toward opening branches for everything and leave them there forever, and then we end up with a packagist page that's quite messy.

[fballiano]

@Flyingmana - I did not consider this option, but it must be done only by a maintainer with a specific purpose.

yeah, I did this for a few things, but they got deleted by now it seems

That would be another benefit of coauthoring through a PR, the history never goes away ever (as far as I know).

PS: the only branches I removed were release branches, logged at OpenMage/magento-lts#2247, nothing else, unless it was a mistake.

[fballiano]

-1 from me to make 20.0 the main branch as long as the amount of bug fixes and changes merged for v19 is still above 10% of all PRs

Everything goes in v19 only because it's not considered BC but, if v19 was managed like any other LTS, only security fixes would be addes and so the percentage would actually be 95% v20 and 5% v19.

Example: you've a big website that works perfectly fine with v19 and you don't want to upgrate to v20. we introduce a bugfix to v19 fixing (just an example) a tax calculation bug. the website is in trouble now because, right or wrong, the rules changed and you've developed the whole project based on those quirks of v19.

[Flyingmana]

-1 from me to make 20.0 the main branch as long as the amount of bug fixes and changes merged for v19 is still above 10% of all PRs

Everything goes in v19 only because it's not considered BC but, if v19 was managed like any other LTS, only security fixes would be addes and so the percentage would actually be 95% v20 and 5% v19.

Example: you've a big website that works perfectly fine with v19 and you don't want to upgrate to v20. we introduce a bugfix to v19 fixing (just an example) a tax calculation bug. the website is in trouble now because, right or wrong, the rules changed and you've developed the whole project based on those quirks of v19.

you described the 2 extremes.

But nobody said, that BC Features have to go into v19. They could already go to V20 while we still accept general bugfixes in V19

[fballiano]

-1 from me to make 20.0 the main branch as long as the amount of bug fixes and changes merged for v19 is still above 10% of all PRs

Everything goes in v19 only because it's not considered BC but, if v19 was managed like any other LTS, only security fixes would be addes and so the percentage would actually be 95% v20 and 5% v19.
Example: you've a big website that works perfectly fine with v19 and you don't want to upgrate to v20. we introduce a bugfix to v19 fixing (just an example) a tax calculation bug. the website is in trouble now because, right or wrong, the rules changed and you've developed the whole project based on those quirks of v19.

you described the 2 extremes.

But nobody said, that BC Features have to go into v19. They could already go to V20 while we still accept general bugfixes in V19

I didn't describe a BC, that's a bugfix that can and will create problems because big websites already have procedures in place to workaround those quirks. So, again, not everything should go in v19 just because it's not a BC at first glance.

[addison74]

It would be good to discuss.

Would it be possible to have two repositories in OpenMage, one for OpenMage and another for Magento LTS? Thus we would separate these projects once and for all, each one will have its own course. How it is now seems mixed to me, in addition, it's also tiring to keep hearing that a PR goes sometimes there, sometimes beyond, that we can do a BC and many others. OpenMage becomes a main project and will provide Magento LTS with certain PRs if needed.

[kiatng]

Ref discussion #2873, I vote for shifting to v20 as the main branch.

My reasons:

1. v19 and its IE8 support etc is not compatible with the future.
2. v19 is supposed to be an easy replacement to Magento 1, but it is not. Breaking changes such as SOAP services and even security updates may break sites making the updates. I updated a site recently, but had to revert because the same-site cookie introduced here broke the production. That stumped us for more than 12 hours because it didn't happen in development and staging servers. Users using VPN to access the site couldn't maintain the login session. Although it was easily fixed with setting the same-site cookie to Strict, I would say that there is no guarantee v19 is 100% BC.

[colinmollenhour]

Would it be possible to have two repositories in OpenMage, one for OpenMage and another for Magento LTS?

I think this would divide the community, much like M2 did to M1 so am opposed to this.

5. Forbid maintainers and contributos (whoever can write to the magento-lts repository) from creating new branches...

Perhaps "strongly discourage"? It is not such a terrible thing to have a few branches that aren't specifically releases. But agreed that most of the time opening a PR on your personal fork and allowing maintainers to edit is the right approach (my bad!).

As branching and release cycle are very closely related it would be great if we can address the branching strategy in PR #7.

[fballiano]

Perhaps "strongly discourage"? It is not such a terrible thing to have a few branches that aren't specifically releases.

when I started writing this RFC the branches were a mess, now it's kinda not even needed. but still, developers should use their own fork

As branching and release cycle are very closely related it would be great if we can address the branching strategy in PR #7.

when I started writing this RFC the file changed by #7 were in this half baked state that seemed just a template, so you know... I'm ok throwing away what's been done here, if it gets integrated in the other one. but then it should be put in draf stage again, proposed RFC shouldn't be totally changed as it's happening.

[fballiano]

closing because it's superseeded by #7