There aren't really any objections to this, so I'm going to start working towards this. The current head of 3.1 is eb7f7833b6fe21c664196217e66d911c9e83dc45; if we change our mind, it's easy to bring it back from there. Since the branch is being dropped, there's no need to merge anything new into it. Merges coming from 2.1 can go straight into the main branch now.
On Tue, Mar 11, 2025 at 10:08 PM Christopher <ctubb...@apache.org> wrote: > It could be done before a 2.1.4 release, but I agree should that be soon. > For this, I'm more concerned about how it's going to mess up currently > outstanding PRs against 3.1... which I'd like to merge first to minimize > impact. > > On Tue, Mar 11, 2025 at 5:19 PM Dave Marion <dmario...@gmail.com> wrote: > >> I'm wondering if we should implement this plan after 2.1.4 is released >> (which is hopefully soon). >> >> On Tue, Mar 11, 2025 at 5:16 PM Daniel Roberts <ddani...@apache.org> >> wrote: >> >> > 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? >> > > > > >> > >> > > > > >> >> > > > > > >> > > > > >> > > >> > >> >
