Move RFC 0002 (Release Schedule) into accepted

[colinmollenhour]

The RFC 0002 proposal (Release Schedule) is ready for vote. Please add your votes in a +1 or -1 (with feedback) comment.

[fballiano]

+1
can't wait for the new branches

[colinmollenhour]

+1

[justinbeaty]

+1

[addison74]

+1

The only comment is related to the name of the branches. Personally, I would detach myself from these v19 and v20 labels and go for "magento-lts" and "openmage". In this way, we have a well-defined product that has a future (OpenMage) and we have another product that ensures, as far as possible, backward compatibility.

[elidrissidev]

+1

[kiatng]

+1

There are users who expect BC with Magento 1.9, or "magento-lts" as suggested by @addison74. With this RFC:

Relegates v19 to PATCH-only going forward and v19 basically becomes EOL in 2 years.

I interpret it as there won't be LTS for Magento 1.9. After EOL, users would have to upgrade to v2{x} to get continue support. I think that's fair. I like that OpenMage is progressive. Users who want LTS can head over to Mage One.

[colinmollenhour]

That's correct, v19 support has already been going on for nearly three years, two more will be five. There is plenty of time to upgrade as BC is minimal anyway. Also PHP updates alone will require updating third party code so there is no escaping minor updates in the long run.

…

On Mon, Mar 6, 2023, 8:20 PM Ng Kiat Siong ***@***.***> wrote: +1 There are users who expect BC with Magento 1.9, or "magento-lts" as suggested by @addison74 <https://github.com/ADDISON74>. With this RFC: Relegates v19 to PATCH-only going forward and v19 basically becomes EOL in 2 years. I interpret it as there won't be LTS for Magento 1.9. After EOL, users would have to upgrade to v2{x} to get continue support. I think that's fair. I like that OpenMage is progressive. Users who want LTS can head over to Mage One <https://mage-one.com/>. — Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAJOUSAIGJUYEQWIBIQA7DW22EOHANCNFSM6AAAAAAVRKJVCM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[fballiano]

we've 6 votes so far and no vote against this PR (since it was thoroughly discussed before).

[FredericMartinez]

+1

[barbanet]

+1

[orsifrancesco]

+1

[MGAndreasen]

+1

[clotted]

+1

[fballiano]

we've 11 votes now, maybe we could merge this?

[colinmollenhour]

• Create a "main" branch from "20.0" and designate it as the "default" branch in GitHub admin
• Create a "next" branch that is a copy of "main"
• Create a "v19" branch from "1.9.4.x"
• Create a "v20" branch from "20.0"
• Add branch protection rules for "main", "next", and "^v\d+$"
• Add branch protection rule to lock old branches ("1.9.4.x" and "20.0") to avoid accidental merges
• Codify the strategy into the main project README.md file using the descriptions above (See Updated README.md to reflect new RFC 0002 - Release Schedule magento-lts#3139)
• Announce new release strategy in a blog post
• Update all existing PRs for 20.0 to main (Thanks @fballiano!)
• Delete "20.0" branch once there are no more PRs dependent on it
• Update all existing PRs for 1.9.4.x to the appropriate branch (can be done gradually - enlist the help of community members - see Rebasing Guide)
• Delete "1.9.4.x" once there are no more PRs dependent on it

[colinmollenhour]

This is ready for announcement after OpenMage/magento-lts#3139 is merged.

The 77 PRs for 1.9.4.x and 24 PRs for 20.0 need to be rebased onto main. As this is a lot I think ideally the authors will do the rebasing since they know their code best. @Flyingmana would mind handling the announcement? Including a call for PR authors to adopt the new branching strategy by updating their PRs would be great.

Would anyone like to update the public site? For example the wording here and other places should be updated:

Before:

OpenMage LTS is designed to benefit Magento community by offering stable platform after EOL* to continue at least 5 years ahead.

After:

OpenMage LTS benefits the Magento community by offering a stable platform for existing Magento 1 store owners to migrate onto as well as new users who find Magento 2 to be overkill but still want to maintain their own open-source eCommerce platform on a powerful and mature platform.

• Please add PR review to Updated README.md to reflect new RFC 0002 - Release Schedule magento-lts#3139
• Need volunteer to update the public site

[FredericMartinez]

After²:

OpenMage LTS benefits the Magento community by offering a stable platform for existing Magento 1 store owners to migrate onto as well as new users who want to maintain their own open-source eCommerce platform on a powerful and mature platform.

[fballiano]

Delete "1.9.4.x" and "20.0" once there are no more PRs dependent on them (or will PRs just default to "main"?)

I'm not sure but I think those PRPRs would get closed in case the branch gets deleted, but I've a couple of questions:

• if we delete 1.9.4.x how are we releasing patches to v19.x versions?
• are we canceling the v19.5 version?

@colinmollenhour I wanted to quote your message and I instead modified it by mistake, sorry! It should be fixed now.

[fballiano]

• Update all existing PRs to the appropriate branch (can be done gradually - enlist the help of community members)

  • PRs for 1.9.4.x
  • PRs for 20.0

I've rebased all 20.0 based PRs to main, since main was created from 20.0 there was no possibility for conflicts or weird behaviours ;-)

[colinmollenhour]

Guide for rebasing 1.9.4.x PRs onto "main" or "next"

• Your PRs for 1.9.4.x
• Or use gh pr status

Setup

1. Fetch the latest code
2. Assign the REMOTE name you use for OpenMage's repo (e.g. origin or openmage)
3. Assign the appropriate NEW_BASE branch name to a variable (e.g. main for MINOR - use next in case of MAJOR update)

Example:

git fetch --all
REMOTE=origin
NEW_BASE=main

Rebasing/squashing

Start by checking out the PR branch: gh pr checkout <YOUR_PR_NUMBER>. Now use either the Rebase or Squash method below:

Rebase

This uses "rebase interactive" - there are many tutorials.

git rebase -i $REMOTE/$NEW_BASE

If there are too many commits because the branch was merged or it is just a big mess use git rebase --abort and try the Squash method below.

Squash

This is probably easier if your PR has merges or lots of commits - but loses commit history.

1. Reset tree to merge base branch: git reset --hard $(git merge-base --octopus $REMOTE/1.9.4.x)
2. Squash branch into a single commit: git merge --squash HEAD@{1} or git merge --squash $(gh pr view --json headRefName -q .headRefName)
3. Commit the result: git commit
4. Rebase onto the new base: git rebase --onto openmage/main HEAD^

Finally

If rebase has any conflicts, fix them, inspect/test your fixes and use git add and git rebase --continue until rebase is complete.

After rebasing or squashing:

1. Force push rebased/squashed branch: git push -f
2. Edit base branch of PR: gh pr edit --base $NEW_BASE
3. Click the link and inspect the list of commits and the diff to make sure it all looks good.
4. Add label to mark it as rebased: gh pr edit --add-label 'Rebased: RFC-0002'

[colinmollenhour]

• if we delete 1.9.4.x how are we releasing patches to v19.x versions?

There is now a "v19" branch.

• are we canceling the v19.5 version?

I'm not familiar with it.. Since it was already in progress before this was accepted I am not opposed to a 19.5 release even though it would be against the RFC.

[colinmollenhour]

Thanks to everyone who voted! I think this will be a big improvement to the code review and release process!

@Flyingmana I wrote a guide above for rebasing old PRs onto main so we can hopefully get the original PR authors to update their PRs that should still be considered for merge. Feel free to post it somewhere else and link to it or whatnot.

[justinbeaty]

@colinmollenhour Since we are still on 20.x, did we intend to have a v20 branch already?

Alternatively, we could chose to have main be 21.x and next be 22.x.

[fballiano]

yes it seems to me too we shouldn't have v20 branch, as

• main is v20
• next is v21
• v19 is v19