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 Sun, 04 May 2014 05:50:35 GMT


Overall, in favor, but...
1. Confusing tag name
2. Alt. Option 1: just drop the active dev branch, no tag
3. Alt. Option 2: just closeout 1.4 with a quiet administrative 1.4.6
source release
4. Voting under "release" rules is invalid without signed release artifacts


Overall, I'm in favor of EOL'ing 1.4.x, but I'm not sure what an
"1.4.6-eol" tag in SCM would mean to users. The "-eol" suffix couldn't
really be documented anywhere for users to understand how that would
differ from an actual release/tagged version, for users browsing the
SCM tags. I understand a tag is not a release, but to a user, that may
not be clear. It's also very confusing, because it does look like an
updated release... it has a 1-up version number over the last release
(1.4.5), after all. That's very confusing.

To alleviate the confusion, it may be better to call it "1.4-eol" or
something else to indicate that it's not a newer release than 1.4.5
(it's not a release at all).

An alternative option to the 1.4.6-eol tag: just drop the
development/planning branch. (This is the option that was exercised
when this decision was made for 1.3.x). All the relevant code is
merged to newer branches anyway, and the outstanding work planned for
a future 1.4.6 which will never come to pass is not useful to tag
distinctly. Besides, the HEAD commit of 1.4.6-SNAPSHOT will be around
indefinitely, as it's merged to master, so we could achieve a similar
purpose by simply noting its current HEAD commit
[5bd4465c433860624091b0d97892e02f58154e7a] in a message to the mailing
lists, for archival purposes.

Another option: do an actual release vote on a signed 1.4.6 source
artifact. It wouldn't be hard to pass, since 1.4.5 passed, and the
current state of the branch isn't substantively different. We could
just call this an administrative release... no need for release
announcements and such, but it would clear up the name confusion.
1.4.6 would be an actual thing at that point, voted on and approved
for release.

Also, I'm concerned that this is being treated as though it were a
release vote. A release vote requires signed release artifacts:

You can't issue a vote under our rules for releasing without providing
release artifacts on which to vote. While it may still be valid to
have a similar voting mechanism for this kind of thing, what you're
proposing is certainly not a release vote. And given that I can see
arguments for treating it as a release plan cancellation[majority],
though... or code change[lazy consensus]... or even adoption of new
code base[consensus], I think the bylaws may need some clarification
on EOL procedures/voting.

Christopher L Tubbs II

On Sat, May 3, 2014 at 4:41 PM, Sean Busbey <> wrote:
> Accumulo Folks,
> I would like to declare end of life for the 1.4 branch of development. It's
> been active for a little over two years and the release of 1.6.0 means we
> now have three active releases.
> Declaring end of life would mean
> * Posting an ANNOUNCE message to the user list
> * No longer accepting issue fix version targets for future 1.4 releases
> * Removing fix version targets of 1.4.x for existing open issues
> * The end of having a long lived 1.4 related branch in git
> * Removing direct references to 1.4.x releases on our download page
> * No longer linking to the 1.4 related documentation from the main
> navigation area
> Our issue tracker shows that candidate version 1.4.6 currently has:
> * 9 closed issues, none of which are blockers or critical.
> * 1 issue in patch available status, marked critical
> * 18 open issues with a target fix version of 1.4.6, four of which are
> marked critical.
> Because there is existing work, but not yet enough to warrant a release, I
> propose
> that on successful passing of this vote we create a "1.4.6-eol" tag with
> the then
> current state of the development branch.
> Please vote
> [ ] +1 I am in favor of announcing End of Life according to the above plan
> [ ] +-0 I am indifferent
> [ ] -1 I am opposed to the above End of Life plan because...
> I'm treating this like a release vote. Thus, it will be handled with
> Majority Approval:
> to pass it will need 3 committers to +1 and more committers voting +1 than
> -1.
> Vote will remain open for 72 hours, until Tuesday, May 6 2014, 20:40 UTC
> --
> Sean

View raw message