accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joey Echeverria <>
Subject Re: [VOTE] end of life plan for 1.4 branch
Date Mon, 05 May 2014 20:07:03 GMT
On Mon, May 5, 2014 at 3:40 PM, Drew Farris <> wrote:
> I suppose this will be a problem we will encounter with every major/minor
> revision as they age, so we have a good chance to hash out a general policy
> for this.
> I see two categories of actions proposed here:
> 1) Content Changes (e.g: website)
> 2) SCM Changes (e.g: git repo)

There is also the impact on ticket workflow. When a version is EOLed,
I'd not expect the community to provide any additional fixes for that
release line. If 1.4 hangs around, then it creates confusion over what
will happen to tickets filed against it. It also will confuse users as
they may keep filing 1.4 tickets.

> As far as 1 is concerned, I have the sense that there's general consensus
> that we should de-emphasize the 1.4 releases in favor of 1.5 at this point.
> We could go far in doing this by changing the wording on the website:


> From:
> Latest 1.5 release: 1.5.1
> Latest 1.4 release: 1.4.5
> To something else, perhaps:
> Current Stable Release: 1.5.1
> Legacy Bugfix Release: 1.4.5

We used to have something like this, but that lead to some arguments
over which is stable and which legacy. For example, 1.6.0 is out now
so that means that there would be three releases we need to identify.

> I think we also agree that removing Maven artifacts is out of bounds
> because that will cause breakage for all sorts of things. Mirrors will
> likely want to drop release tarballs at some point (e.g for old point
> release versions like 1.4.3, 1.4.4) but I'm not sure how they are signaled
> to do so. I'm generally in favor of keeping the documentation for old
> versions around. (E.g: you can still find docs for Lucene 3.0.3 at Apache
> and it's ancient!)

Absolutely. We should never delete released artifacts.

> I don't think it makes sense to tag a 1.4.6 release until someone is
> prepared to follow the release process and produce votable artifacts. At
> this point I'm hearing that a) work isn't done and b) there isn't
> sufficient reason to create 1.4.6. I don't think that there is any onus on
> the Accumulo community to ever produce a 1.4.6 release, but we should not
> do anything that will prevent that from happening or make it difficult to
> do so. There are still folks out there that are using 1.4 actively and who
> knows what darkness lurks at the heart of Accumulo that might need to be
> fixed.
> Could someone explain why we would want to ever delete the 1.4.x branch?

I think you want to delete the branch because of our Git workflow[1]
which is to always target a patch for the earliest, non-end-of-lifed
version. You could argue that the documentation and mailing list
announcement are sufficient to declare the branch EOLed, but I don't
think that's strong enough for a casual contributor.

The purpose of the EOL is to say that the community *won't* create a
new 1.4 release. If you need to stick with it for whatever reason,
it's expected that you and/or your support vendor will backport
required patches and cut your own releases. Nothing here will prevent
that. In fact, creating the tag for the work that was in progress on
the 1.4 line post the 1.4.5 release should make that easier.

> So, in summary:
> 1) I agree it makes sense to clearly market 1.5 as the current stable
> release and market 1.4 as something old that you only want to start using
> if you're already using.
> 2) I can't see any good reason to do anything with tags or branches at this
> point.
> It is not clear to me why we would want to do anything in SCM to eol 1.4,
> as long as we cover the website. I'm interested if there are specific
> mechanical reasons.



View raw message