accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Drew Farris <>
Subject Re: [VOTE] end of life plan for 1.4 branch
Date Tue, 06 May 2014 12:34:06 GMT
Thanks for the response Joey.

It sounds as if there's agreement on a number of points and it sounds like
I'm the only person not in favor of deleting the branch and creating a tag
a this point. Also, bug management is an interesting issue. Thoughts
in-line below:

On Mon, May 5, 2014 at 4:07 PM, Joey Echeverria <>wrote:

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

If people find ticket-worthy issues in 1.4 after it's end-of-lifed wouldn't
we expect them to file a ticket against that version? Shouldn't these
tickets reflect known issues with a release of software that people use?
Regardless of the desire of the development community to produce new
releases of a specific branch, it is a service to the community of users to
be able to record known issues (even if these will ultimately result in a
wontfix resolution). Google does a very good job indexing the Apache JIRA.

Furthermore, issue reporting activity is a reflection of real-world use
which should naturally migrate to future versions, and if people aren't
migrating to future versions, we have bigger fish to fry.

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

Ok, so, we list three releases instead of two. Two of them happen to be
considered stable. If there's confusion in the user community, we likely
need to do a better job explaining which one to use a la tomcat [1]

Current Stable Releases: 1.5.1, 1.6.0
Legacy Bugfix Release: 1.4.5

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

Who are we trying to protect here? and what are we trying to protect them
from? If casual contributors can't keep up with the current state of the
code and repository via the mailing list or website, I'd worry either about
the quality of their contributions or the quality of the documentation the
community is producing in terms of the current state of the project. If
folks that would commit to the project aren't aware of where merges should
be made I'd worry that they shouldn't be committing to the project in the
first place without guidance from the community.

So, to summarize:

I agree it's time to end of life 1.4 in that I'm in favor of stating
clearly that users should not expect new releases of 1.4.x and new projects
and migrations should use some other version (preferably 1.6.0)

I'm against stating that a new release of 1.4 will >never< be made or must
>never< be made - and as a result against deleting the 1.4.x development
branch in favor of a tag.

I'm also not in favor of preventing people from documenting the issues they
find with 1.4 as tickets in jira.



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