[Evergreen-dev] [Eg-newdevs] Release branch proposal
Jason Stephenson
jason at sigio.com
Tue Mar 5 13:20:39 EST 2024
Hi, all.
I know I have spoken on this topic before, but I'm going to answer some
of Jane's questions below with my suggestions based on what I've seen
in another project: https://github.com/wesnoth/wesnoth.
On 3/5/24 10:39, Jane Sandberg via Evergreen-dev wrote:
[Snip]
>
> Some more points where we should discuss further:
> * Using git tags instead of tag branches (git tags seem popular, but for
> some it would be a supplement to our point release branches; for others,
> it would be a replacement)
> * What version should be stamped while the release branch is between
> versions
I think git tags should replace tag branches. If you look at the above
repository and some others, this is what they do. They use tags for
release versions. They still have development branches for their release
series: 1.16, 1.18, etc.
On the second question, I like how the Battle for Wesnoth project
handles it. The 1.16.10 release gets made and files are "tagged" with
appropriate version numbers. This commit is tagged as 1.16.10. The
following commit restamps the files with version 1.16.10+dev. This is
then changed to 1.16.11 when the latter is released and so on.
In the main branch of Wesnoth, the version stamps are odd series which
get bumped up to the next odd number the next even number series is
released. For example, the master branch is currently at 1.19.0-dev.
(Despite that the 1.18 branch version is at 1.17.26+dev.)
Without getting into too many details about possible differences between
"-dev" and "+dev" or even worrying about versions in our main branch, I
think it might be useful to adopt a similar convention for our series
branches.
>
> I understand the concern about having a repo with 3.12.4 work but a
> 3.12.3 stamp. I'm curious what you think about the opposite scenario:
> * The release team releases 3.12.3
> * As part of this process, after generating the tarballs, make_release
> queues things up for the next release by stamping 3.12.4
> * We add new bugfixes to the repo. The repo is stamped as 3.12.4, the
> commits we are adding to it will be in 3.12.4 (even if it's not the
> absolute final 3.12.4 release)
> * When 3.12.4 is released, there is no need to restamp anything when
> preparing the tarball. We set a rel_3_12_4 git tag at the appropriate
> commit in rel_3_12, and make_release subsequently re-stamps to prepare
> for 3.12.5.
This could work, too. Going up a version. I think it would be useful to
add "-dev" to the version strings to indicate it is development. We
could also add "-alpha," "-beta," and "-rc" for the .0 iterations before
the final release.
>
> Please let me know if I missed or misrepresented anything in the
> summary, and your further thoughts on the topics mentioned above. And
> also, should we try to make a decision about this in the next developer
> meeting?
>
> -Jane
>
> El lun, 26 feb 2024 a la(s) 2:01 p.m., Mike Rylander
> (mrylander at gmail.com <mailto:mrylander at gmail.com>) escribió:
>
> 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
> <mailto: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
> <mailto: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 <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
> <mailto:Eg-newdevs at list.evergreen-ils.org>
> > http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/eg-newdevs
> <http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/eg-newdevs>
>
>
> _______________________________________________
> Evergreen-dev mailing list
> Evergreen-dev at list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
More information about the Evergreen-dev
mailing list