@busbey, just a slight clarification to the plan you describe in the thread on the user@ list:
Since we'd actually be releasing the latest from 1.5 development branch, there won't be any extra dangling unreleased commits to tag like we did for "1.4-development-closed", so there won't be anything to archive. It will be fully "archived" in the 1.5.3 tag, and thus not exactly the same as what we did for 1.4. I offer this clarification here, rather than on the user@ list, because it's entirely a technicality which doesn't change the spirit of what you said. I just wanted to make sure we were on the same page. Please let me know if we're not. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Thu, May 21, 2015 at 3:53 PM, Keith Turner <ke...@deenlo.com> wrote: > +1 for 1.5 EOL > > On Tue, May 12, 2015 at 2:18 PM, Christopher <ctubb...@apache.org> wrote: > >> How do we want to EOL 1.5? >> >> Personally, I was thinking (soon after 1.7.0 is released): >> * Release and tag 1.5.3 >> * Remove 1.5 branch to focus active development on newer versions >> * Be willing to branch from the 1.5.3 tag to rapidly release a 1.5.4 >> in response to critical bugs >> >> My biggest concerns are: >> 1) We turn exhausted people off by doing burdensome release testing, >> which delays bugfixes in 1.5, and >> 2) We get into a situation where 1.5.3 has some bugs that we never >> fix, which sends a confusing message to stick with 1.5.2. >> >> There's also the concern that there's a fair amount of work that was >> put into 1.5.3, and I'd hate to have those contributions not be >> available to users of 1.5. >> >> I figure that so long as we're willing to fix critical bugs, we can >> formally cease active development (EOL), without going so far as to >> say that 1.5 users are completely screwed if a critical bug is >> identified. >> >> What I'm describing isn't really an EOL date, so much as an EOL period >> which begins when we cease active development on 1.5, and ends >> organically at some arbitrary point in the future when people stop >> reporting critical bugs (or we reach a point where maintaining it is >> too costly... a sort of "EOL-2"). >> >> Another way to look at what I'm suggesting is switch from a "sustained >> development" model to a "branch to fix and release" model, where >> patch/bugfix releases are more narrowly scoped and can occur more >> rapidly, on demand. >> >> Thoughts? Alternatives? Variations? Objections? >> >> -- >> Christopher L Tubbs II >> http://gravatar.com/ctubbsii >>
