Automate Release Process

[Flyingmana]

Summary (*)

Creating a release is still a very manual process.
The current Release process looks like this:

• Change Mage.php OpenMage Version
  • create a locally signed commit for this (when we have 2FA enforced on the org, we may also allow signed by github)
  • an example for this is cbeebfa
• Create Draft Release in Github for this Commit
  • the tagging scheme is vx.y.z so for example v19.0.5
• Write/Link Changelog listing all merged PRs with Issue/PR IDs
  • Check name of merged PRs if they are easy understandable for what was merged
  • Rename if necessary
  • you can use this page to see all the changes https://github.com/OpenMage/magento-lts/commits/1.9.4.x
  • also gitk or any other git history visualizer can help
• Check if the PRs mentioned BC breaks, possible Issues or already noticed Bugs
• Check CI Run for version commit
• Publish Release if no Issues are appearing

after done for Version 19, do a merge upstream into the current next supported version(s), and repeat the release process there.

Remember to also check before Releasing, if there are any suspicious commits which are not related to any PullRequests

• git fetch --tags
• git merge v19.y.z

@Flyingmana did start to work on some tooling to make some things easier, which currently helps creating the changelog
https://github.com/Cotya/maintainer-tooling

This is currently basically a process which needs to be done in one go, which builds up on the work needed for it.

Proposed solution

• have a first step for release creation to start in a release branch like release-19.4.x (to reduce possible conflicts by PRs merged after starting to work on a new release)
• Fast-Forward the Release branch with the according main branch (fail if a fast-forward is not possible because of changes in the release branch not yet in the main branch)
• automatic update of version number
• automatic update of changelog using the generated log of https://github.com/Cotya/maintainer-tooling (might need some changes on the tooling end
• have this as part of a github action triggered by a manual dispatch and failing, when there is already a new release in progress
• have a lock file(?) needing to be removed manually before the next step can start, as the changelog needs to be checked manually again if something is missing or needs to be extended. Also this is the time where security fixes are merged into the public branch
• merge in downstream versions if not happened yet (should probably happen after changelog generation, as we currently just refer to the changes there via "includes all changes from version x.y.z)
• make sure the referenced changes have all BC breaks noted in the changelog
• have another github action for creating the (draft-)release and do some checks before and merging the release back into the main branches (or creating a PR if there is a merge conflict? merge conflict should not let the build fail here)

[macoaure]

can we create the 'CHANGELOG.md' file? add a pattern, like keep a changelog?

[Flyingmana]

if you think it works better then https://github.com/OpenMage/magento-lts/tree/20.0/.github/changelog

[luigifab]

Can I suggest to update phpstorm metadata before each commit "bump version"?

[fballiano]

would you be ok to bump the release number right after the release itself?

I'll try to explain better.

Right now, in the Mage.php we've 19.4.15, but if I clone the repo I wouldn't get a 19.4.5... I'd get a dev-master version... so I'd bump the version number right after the release so, if I clone the repo, I get a version number which is not released yet (which I think it's good).

[fballiano]

I know it's probably redundant but yesterday night I created a script to generate the list of merged PRs since last release, it's not complete like @Flyingmana's but graphql is kinda complicated, plus there's symfony so... it could be maybe useful anyways

https://fabrizioballiano.com/om/changelog/

it automatically updates every couple of hours

[Flyingmana]

would you be ok to bump the release number right after the release itself?

I'll try to explain better.

Right now, in the Mage.php we've 19.4.15, but if I clone the repo I wouldn't get a 19.4.5... I'd get a dev-master version... so I'd bump the version number right after the release so, if I clone the repo, I get a version number which is not released yet (which I think it's good).

sounds ok for me, as long as the version number for releases matches the released number

[fballiano]

sounds ok for me, as long as the version number for releases matches the released number

that would have to be checked but I guess that if a very big change is going to be merged (which would need a major version number change) than the version number would be changed at that time :-)

[Flyingmana]

Major version numbers are determined by branch name, and if you have a look at this code here, kind of predefined currently.

https://github.com/OpenMage/magento-lts/blob/1.9.4.x/app/Mage.php#L211-L238

basically, if something would need a new major version, it should only go into the branch of this major version

[fballiano]

Major version numbers are determined by branch name, and if you have a look at this code here, kind of predefined currently.

That is also true, so it shouldn't be a problem anyway ;-)

[tmotyl]

My view on branches:
We should have 2 stable branches one for 1.9 line and one for 20.x line.

• each PR is targeted to one of these branches.
• Regularly changes from 1.9 are merged to 20 branch
• release is done from these branches

In case we need to prepare a release and want to avoid that sb merge PR to given branch, we should declare a "Merge freeze" among maintainers (e.g. on discord or on github message). And once release is done, merge freeze is called off.

Having a stable branches for each product line allows people to follow recent development and use it on production even if the release was long ago. For my customers I take a fork of openmage, and create a branch there which is built on top of 20.0.x-dev branch. Then I 'm applying some commits (which are not yet merged in openmage repo) and use this version in prod.
Regularyly, when 20.0.x branch gets new commits, I rebase my custom branch on top of it.

[Flyingmana]

In case we need to prepare a release and want to avoid that sb merge PR to given branch, we should declare a "Merge freeze" among maintainers (e.g. on discord or on github message). And once release is done, merge freeze is called off.

we are (in theory) 19 Maintainers, with no medium were even half of them is reliably reachable. I dont think this is an option. Additionally there is the potential, this can take a week.

[fballiano]

Can I suggest to update phpstorm metadata before each commit "bump version"?

how can we do that?

[luigifab]

I suppose (but never tried):

n98-magerun dev:ide:phpstorm:meta