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
