The proposal sounds good to me as well.
On Fri, Mar 7, 2025 at 4:33 PM Keith Turner <ke...@deenlo.com> wrote: > > That proposal sounds good to me. The 3.1 branch could be deleted sooner > rather than later. Creating the 3.1-deprecations branch does not seem > urgent and could be done at any time. When the 3.1-deprecations branch > does exists will need to agree on how to do merges from 2.1. Seems like > merges from 2.1 will not need to go through the 3.1-deprecations branch in > general, could on an as needed basis though. > > > > On Thu, Mar 6, 2025 at 5:05 PM Christopher <ctubb...@apache.org> wrote: > > > 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? > > >> > > > >> > > > > >
