[Evergreen-dev] Evergreen point release discussion

[Lussier, Kathy]

Hi all!

I was planning to write this message as a reply to Andrea's RC
announcement, but then decided the question deserved its own thread. It
turned out to be a longer message than I planned, so the TLDR version is 1)
please do one more 3.10 release before retiring the branch 2) let's talk
about regular point release schedules and 3) yes, I think point releases
are important.

I first want to commend the 3.12 release team on a great release process.
It's the first time in five years I've been able to closely watch the
release process, and you all seemed to work well together, communicated
well with the community, and wrangled contributors so that we saw a lot of
bug fixes and new features merged. It was exciting to watch and you should
all give yourselves a pat on the back for a job well done!

Now that the release is almost out the door, I would like to raise the
question of point releases for our other supported Evergreen versions and
whether we might consider getting ourselves back on a regular point release
schedule. With such an effective release team that has also been building a
lot of skills around release building, it's a good time to tackle some
difficult questions around point releases.


   - With all of the bug fixes that have been merged since the July
   security release, will we be posting point releases at the same time 3.12.0
   is released?
   - Looking at the Evergreen Release Schedule -
   https://wiki.evergreen-ils.org/doku.php?id=dev:release_process:schedule
   - I see 3.10 is technically at End of Life, but there are a lot of bug
   fixes posted to the 3.10 branch. Since this page also says there will be
   "bug-fix point releases on the third Wednesday of every month", which no
   longer happens, I'm hoping we can have some flexibility on end-of-life
   dates so that all bug fixes merged to the branch eventually become part of
   a tagged point release.
   - Can we discuss the possibility of returning to a regular point release
   schedule and identifying what that schedule should be? Monthly may be too
   frequent. How about bimonthly or quarterly?
   - I'm still becoming familiar with the team approach to releases. In the
   release manager days, the manager became the maintainer for their release
   to ensure the bug-fix schedule was met. How does release maintenance work
   under the team model, especially when there are some people who stay on the
   release team from one release to another? Who takes responsibility for
   ensuring that 3.12 continues to get bug fixes? Without a designated person
   or team to maintain a release, the schedule is more likely to slip.

An alternative, perhaps, is to no longer issue point releases and to expect
Evergreen sites / support providers to pull from the primary branch for a
particular release, which will include any bug fixes that have been merged
since the .0 release. However, I think there are a couple of arguments to
be made for continuing point releases:


   - Maintaining regular point releases forces people to more regularly
   review pullrequests and merge bug fixes. This community is made up of many
   deadline-oriented people, and the deadline of a pending point release has
   been helpful in maintaining a regular review of patches. After the beta
   release was cut, I noticed a lot of bug-fix merging happening at one time.
   In many cases, the patch had been contributed months before. If we had
   scheduled a point release sometime between July and November, some of those
   patches may have already been merged during the point release process,
   which would have lessened the work required to put the 3.12 release out.
   - A point release also offers an opportunity to clearly communicate the
   bug fixes that have been merged in the form of release notes. Not everyone
   keeps a close tab on what is being merged into our release branches. As a
   result, a fix may have already been provided for a bug that's causing
   problems at an Evergreen site. Without the release notes, that site may not
   know to ask that the fix be loaded on to their production system to
   alleviate the pain they are experiencing.

This may be a good discussion for next week's dev meeting, but I have a
meeting conflict and won't be able to attend. Perhaps we can have some
discussion ahead of time on the list.

Thank you and have a great weekend!

Kathy
--
Kathy Lussier
she/her
Executive Director
NOBLE: North of Boston Library Exchange
Danvers, MA
978-777-8844 x201
www.noblenet.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-dev/attachments/20231208/bf688dd2/attachment.htm>