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?
> > > > >> >
> > > > >>
> > > > >
> > > >
> >
>

Reply via email to