I agree with the proposed steps for the 3.1-deprecations branch. If we are dropping the 3.1 branch, when should we change our merge strategy for 2.1 changes?
There's a couple of on-going efforts that are resolved in preparation for the 2.1.4 release. Should we continue to merge them forward via the 3.1 branch or just create separate PRs targeting 2.1 and main? On Sat, Mar 8, 2025 at 9:01 AM Christopher Shannon < christopher.l.shan...@gmail.com> wrote: > 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? > > > >> > > > > >> > > > > > > > >
