I agree. Having a final 1.4.6 release and not creating a 1.4.7-SNAPSHOT branch seems like the path of least confusion.
On Mon, May 5, 2014 at 11:04 AM, Bill Havanki <bhava...@clouderagovt.com>wrote: > +1 > > Having a plain "1.4.6" release would be nice (I don't like the "-eol" tag), > but I'm fine with any other plan that closes out 1.4 with a modicum of > clarity for users - for example, a tag off which someone could fork and > carry on development if they care to. > > I can assist with adjusting the site after EOL with moving doc links etc. > > Bill H > > > On Sun, May 4, 2014 at 4:04 PM, Sean Busbey <bus...@cloudera.com> wrote: > > > Hi Christopher! > > > > Responses inline > > > > > > On Sun, May 4, 2014 at 12:50 AM, Christopher <ctubb...@apache.org> > 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: > > > 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. > > > > > > > > > > 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? > > > > -- > > Sean > > > > > > -- > // Bill Havanki > // Solutions Architect, Cloudera Govt Solutions > // 443.686.9283 >
