-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. Also, I'm concerned that this is being treated as though it were a release vote. A release vote requires signed release artifacts: http://www.apache.org/dev/release.html#what http://www.apache.org/dev/release.html#approving-a-release 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 http://gravatar.com/ctubbsii On Sat, May 3, 2014 at 4:41 PM, Sean Busbey <[email protected]> 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
