accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <>
Subject Re: [VOTE] end of life plan for 1.4 branch
Date Tue, 06 May 2014 16:12:34 GMT
replies inline

On Tue, May 6, 2014 at 8:21 AM, Drew Farris <> wrote:

> On Tue, May 6, 2014 at 8:53 AM, Christopher <> wrote:
> > I don't see how that affects removing of the branch for active
> > development. If an issue
> > warrants it, that branch can always be reopened. Removing it indicates
> > that it's not expected to be reopened, and that we've agreed to focus
> > on new versions.
> >
> I don't like removing branches because forces those folks who are
> maintaining their own 1.4 branches to figure out how to fix things locally
> when the remote branch they're tracking goes away. Is it sufficient to tell
> folks to do the following to address this?
> git rebase --onto 1.4.6-SNAPSHOT-eol 1.4.6-SNAPSHOT 1.4.6-SNAPSHOT-local
> What happens if the branch is deleted and then is reopened at a later time?
> Are there further machinations that a developer maintaining a 1.4.x branch
> much go through to get back on track?
> Perhaps this is just the way with git, and I'm trapped in the mindset of
> long-running branches that run parallel to major revision development and
> aren't targeted at a specific point release. In looking at this I'm
> reminded that the Accumulo community has chosen the latter path where
> branches are short-lived and targeted at the next release.

Yes, I'd say your workflow is just at odds with our branch-and-merge
strategy. The work is no different then what you'd have to do when we cut a
release and the branch changed from 1.4.5-SNAPSHOT to 1.4.6-SNAPSHOT.

Hopefully with the compatibility focus changes in 2.0.0, you'll be seeing
more obviously short lived minor version branches that reappear briefly for
bugfix and this will be more obvious.

> > I'm not sure if that means we should archive the 1.4.x
> > versions in JIRA, so people can mark those versions as affected or
> > not. Maybe it'd just be useful to just archive 1.4.0-1.4.3, and leave
> > 1.4.4/1.4.5 unarchived. (I suggest the last two versions of 1.4, only
> > because the last version introduced a lot of changes that people may
> > be reluctant to update to, if they aren't transitioning to hadoop 2).
> >
> I see JIRA being useful as both a work tracking/planning tool >and< a user
> support tool / record of project history (like commit history). Would
> archiving releases prevent historic issues from being findable via google?

Tickets that only impact archived versions remain in Jira, e.g.
ACCUMULO-661 that only impacts the 1.3 line[1] and they are still
searchable in major search engines[2].

Because Jira stops accepting archived versions in autocomplete fields, you
can't use the simple search to find all tickets that impact a particular
archived version, but you can use advanced search[3]. Once you have
completed an advanced search, you can actually switch back to basic and
things will work (though it will warn you that your version choice is



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message