accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: [VOTE] end of life plan for 1.4 branch
Date Tue, 06 May 2014 12:53:09 GMT
I share your concern about stating that a new release of 1.4 will
*never* be made or *must never* be made, but 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 also have no problem reporting issues in JIRA as affecting the
version they are using. However, we really want to focus on bugs that
still affect a supported version, so a report against an older version
that does not also affect a newer one isn't very useful for issue
management. 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).

Christopher L Tubbs II

On Tue, May 6, 2014 at 8:34 AM, Drew Farris <> wrote:
> 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.
> Drew
> [1]

View raw message