[Evergreen-dev] [Eg-newdevs] Release branch proposal

[Mike Rylander]

I'm +1 to this proposal, especially in spirit (that is, automate more
and reduce non-automated duplicate steps to a minimum)!

One bit of soft push-back on a detail below...

On Mon, Feb 26, 2024 at 3:42 PM Galen Charlton via Eg-newdevs
<eg-newdevs at list.evergreen-ils.org> wrote:
>
> Hi,
>
> On Mon, Feb 26, 2024 at 11:02 AM Jane Sandberg via Eg-newdevs <eg-newdevs at list.evergreen-ils.org> wrote:
> > My proposal would be to make all needed changes to the release series branch,
> > and then create the tag branch directly from the release series branch when all
> > these steps are done.  So, at the time of release, rel_3_12 and tags/rel_3_12_2
> > would be identical, before rel_3_12 starts to accumulate bug fixes for the next release.
>

[snip]

>
> > Having these things in the release series branch may cause some kind of
> >  problem that I'm not familiar with.
>
> I think the main thing will be ensuring that any tooling that updates the version numbers is rock solid. We might also consider, immediately after doing a release, doing a commit that updates the version numbers again to clearly indicate that the series branch is back to a pre-next-version mode.
>

IMO, for humans, having a version number stamped on something that is
actually that-version-plus-more is asking for trouble.

So, I think we should keep the release "tag" branches because of that,
as a form of repo hygene.  Having a pair of interstitial commits each
month (ha!) to mark the release, then tag that commit /as/ the
release, and then a commit to /un/mark the release version number in
the code seems messier on balance than having a branch with a single
version-number-update commit.  Bonus: the branch graph will also show
the cul de sac that is each release version.

I realize that the version number is the only thing identified in the
process /today/ that we'd (well, definitely "I'd") want to roll back
after tagging, but as soon as we have two things (or more) then we'd
be introducing blocking after-release checklist items that are needed
before we can open the repo up for cherry picks and merges.  A release
branch lets those continue without a general workflow pause for new,
additional cleanup, and down the road if we need more than the version
update to be recorded for a release then we have time and space in the
release branch.

A parallel to the release versioning (and I think it was mentioned in
the thread before) would be to update the series-level version
stamping as soon as the series branch is created.  This has the
benefit of priming the release branches for simpler updates AND
automated cross-checks that you're stamping a release for the intended
branch -- does the series you're releasing from have a version number
in the code that is a prefix of the release number you're building? --
and makes "change the version number in the code" the first (and only,
maybe, for release branches) commit you should see at the branch point
from its parent, and creating that commit on the new branch should the
first thing a committer should be doing when creating a branch in the
main (not working) repo, for either a new series OR a new releases.
"new branch? new version number!"

We can still use true git tags against the tip commit on the release
branch to create an immutable artifact in the repo and even work
towards having make_release require (or create?) those true git tags,
but a process cleanup and improvement now seems more attainable, or at
least less disruptive, than changing our definition of "release-time
git thing".

Thanks!

--Mike

> Regards,
>
> Galen
> --
> Galen Charlton
> Implementation and IT Manager
> Equinox Open Library Initiative
> gmc at equinoxOLI.org
> https://www.equinoxOLI.org
> phone: 877-OPEN-ILS (673-6457)
> direct: 770-709-5581
> _______________________________________________
> Eg-newdevs mailing list
> Eg-newdevs at list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/eg-newdevs