[Evergreen-dev] Release branch proposal

[Jason Stephenson]

Hi, Jane,

Thanks for bringing this up.

My responses to specific parts of the proposal are in line below.

On 2/26/24 11:00, Jane Sandberg via Evergreen-dev 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.

I am in favor of this proposal. We could also eliminate tag branches and 
use actual git tags, like we do with OpenSRF. (We could also require 
committers to sign the tags with a cryptographic key.)

> 
>  From my limited perspective, here are the pros:
> 
>   * It would eliminate any errors that could arise through differences
>     in the release series branch and the release tag branch (e.g. not
>     forward-porting the upgrade script to rel_3_12)
>   * We'd keep po files in the git repo, making it easier to see what has
>     changed from release to release, and making it easier to set up a
>     localized environment from the git source.

Aside: I'd like to have a conversation about translations and moving 
them entirely into the git repo. This is not the time for that conversation.

>   * Our public documentation
>     <https://docs.evergreen-ils.org/docs/3.12/installation/server_upgrade.html#_upgrade_the_evergreen_code> would include the actual version numbers and file names for the most recent release in a series, rather than a bunch of Xs.
>   * Manually changing the version string in
>     Open-ILS/src/perlmods/lib/OpenILS.pm would be less of a brain teaser
>     each time (this may be a personal problem, but it is easier and less
>     error-prone to just increment the number that's already there than
>     delete "2.4" and try to figure out the correct format from scratch).

I have a script to do this and the other file version updates that I use 
when making custom branches: 
https://gist.github.com/Dyrcona/933dd1a2e9035fdc48162dbcfcb51a2d. That 
is, this could be automated as part of the release process, and I am not 
certain why it was skipped.

>   * I tend to visit the release series branches more often than the
>     release tag branches.  For those like me, it can make the release
>     process more visible.

I occasionally use the release tag branches when making new custom 
branches for testing and production upgrades. Dropping the branches and 
switching to tags would not affect that.

I currently base my customization branches on main and the rel_x_y 
branches. This is what I recommend everyone do with local customization. 
It's easier to cherry-pick/merge FROM rel_x_y TO rel_x_y_z than going 
the opposite direction or to/from main.

> 
> 
> Cons:
> 
>   * Having these things in the release series branch may cause some kind
>     of problem that I'm not familiar with.

Some people might be bothered that the version files all say 3.12.2 when 
there is code in the branch that is not in the actual 3.12.2 release.

I can't think of any technical issues with this, however.

>   * People may have tools that help them roll releases that would need
>     to be changed.

Yes, me! Don't let that stop this, though. I can make the changes.

We may need to adjust the make_release script. This would be a good 
opportunity to split it up into smaller pieces that can be run 
individually. We could also add features, such as version stamping 
OpenILS.pm. This could also eliminate some (if not all) of the need for 
local upgrade scripts, such as mine.

> 
> 
> Please let me know your thoughts, especially if there are any cons that 
> I have missed, or prerequisites we would need before making such a 
> change.  I'm not proposing this for the in-progress 3.11.4 release, by 
> the way, just for the future.

Yes, we ought to pick a starting point. It might not be too late to 
introduce this for 3.12, but maybe others think it is. That's a part of 
this discussion: if we do this when do we start?


> 
> Thanks for considering!
> 
>    -Jane

Cheers,
Jason Stephenson