I have completed the migration of all open PRs to have a base branch of
main that previously had a base branch for 3.1.
I have also completed migrating all the PRs and issues on GitHub under the
3.1.0 milestone to the 4.0.0 milestone.
And finally, I've deleted the 3.1 branch, which was still at
commit eb7f7833b6fe21c664196217e66d911c9e83dc45.
That commit is still contained in the main branch, so it can be easily
reconstituted if we decide later to reverse this decision.
I'm sure some people still will have a 3.1 branch in their local clone or
on their GitHub fork, so I wouldn't be surprised if somebody accidentally
creates a new 3.1 branch accidentally, as part of a git push, but we can
deal with that when/if it happens.
For any local working branches, or any open PRs that were migrated, I
recommend updating your branch by merging the upstream main onto your
branch.
For example:
$ git remote update
$ git checkout myWorkingBranch
$ git merge upstream/main
In case anybody is interested, I have a project called git-sync at
https://github.com/ctubbsii/git-sync that helps keep your working branches
up-to-date with remote tracking branches. It can help save a few manual
steps. However, you'll still need to merge the upstream branch onto your
own local branch for cases like this.
On Wed, Mar 12, 2025 at 2:25 PM Christopher <ctubb...@apache.org> wrote:
> 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?
>>> > > > > >> >
>>> > > > > >>
>>> > > > > >
>>> > > > >
>>> > >
>>> >
>>>
>>
