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 Sun, 04 May 2014 20:04:29 GMT
Hi Christopher!

Responses inline

On Sun, May 4, 2014 at 12:50 AM, Christopher <> wrote:

> -1
> Summary:
> 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
> Exposition:
> 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.
I would really like to avoid doing a 1.4.6 release unless someone both
feels strongly about the need and is also willing to shepherd through the
testing process. The issues closed against it to date don't add
substantively to the 1.4.5 release enough to justify the time investment in
testing, IMHO.

I would be fine with either dropping the tag entirely or using something
like 1.4-eol. I am inclined to have a tag we can refer to in any
announcements, because they are easier to deal with for casual developers.

Presuming no one wants to volunteer to handle a 1.4.6 release, could we
handle the tag naming as a follow-on action since it is just a code change?

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

My apologies for the lack of clarity. I only meant the phrasing "treat like
a release vote" to convey the relative importance I give the topic and to
offer some reasoning on why I was looking for stronger committer buy-in
than simple lazy approval. I did not mean to imply that this actually *is
a* release vote.

I agree that the bylaws as they stand could use clarification on EOL.
However, I think planning would go smoother for our users if we
incorporated EOL timing and procedures into a defined lifecycle for major
versions rather than leaving it as an independent voting action. Since this
is part of a larger, more involved topic would you be fine with having it
handled as a part of our discussions around the 2.0.0 version change rather
than tying up the sunset of 1.4?


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