+1 to making sure we have a 1.5.3 before stop dev I'd like to make sure we get through some testing of 1.5 -> 1.7 upgrade testing before declaring dev over, just to give people more assurance that they can upgrade off of the version.
On Tue, May 12, 2015 at 1: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 > -- Sean
