If we go through with this idea (which I think is reasonable, if nobody else weighs in to suggest an alternative, or to object), then we would do something like these steps:
1. Update PRs and issues currently pointing to 3.1 to point to 4.0/main 2. Delete the current 3.1 branch (ensuring everything is merged to main first) 3. Create a 3.1-deprecations branch from 3.0.0 tag (name should disambiguate from the current 3.1 branch) 4. Identify any API removals in 4.0 that must be marked deprecated for a 3.1.0, and apply them to that branch 5. Update build as needed to address any build failures or license issues (like updating copyright dates in NOTICE files) 6. Release 3.1.0 before 4.0.0 is released (at some point before... not necessarily urgent) On Wed, Mar 5, 2025 at 6:44 PM Christopher <ctubb...@apache.org> wrote: > Great idea! I don't know how well it will work in practice... I remember a > lot of the deprecation removals required a fair bit of disentangling in > 3.0. It is probably not so bad for stuff we want to remove in 4.0, though. > > On Wed, Mar 5, 2025 at 6:27 PM Dave Marion <dmario...@gmail.com> wrote: > >> "Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backward >> compatible functionality is introduced to the public API. It MUST be >> incremented if any public API functionality is marked as deprecated..." >> >> Ref: https://semver.org/#spec-item-7 >> >> If we wanted to maintain semver compliance, then we could create a new 3.1 >> branch off of the 3.0 tag that contains solely the deprecations and >> release >> that. That 3.1 version would require very little testing. >> >> On Wed, Mar 5, 2025 at 2:47 PM Christopher <ctubb...@apache.org> wrote: >> >> > I was recently in a conversation where the question was raised about >> what >> > future versions of Accumulo are expected. >> > >> > There was a time during the elasticity/4.0 development, before that was >> > merged into the main branch that I thought it would be a good idea to >> have >> > a 3.1 LTM release. However, most of the work continued happening in the >> > elasticity/4.0 branch, and that has since been merged into the main >> branch. >> > >> > There was still an idea that 3.1 as a non-LTM release would be a good >> idea >> > as a chance to deprecate some things being removed in 4.0, to follow >> > semver. However, it is questionable whether 3.1 is even something we'd >> want >> > to bother with doing a release at all. >> > >> > So, I figured I'd poll the community and see what people were >> interested in >> > doing. Here's the two options I was thinking, but there could be more >> > alternatives to consider: >> > >> > 1. Drop the 3.1 branch and drop any plans for a 3.1 release. Make note >> of >> > any semver violations in the release notes for 4.0 when it's ready. Make >> > sure upgrades work from 3.0 non-LTM and 2.1 LTM >> > >> > 2. Do a bit of release testing for 3.1 and try to get a non-LTM release >> > out. This allows us to follow semver but may create extra release >> testing >> > and upgrade testing work. Make sure upgrades work from 3.1 non-LTM and >> 2.1 >> > LTM >> > >> > Does anybody else have any thoughts on what we should do with the 3.1 >> > branch? >> > >> >
