Feel free to include user@ sooner, if you wish. The reason I hadn't already was because my suggested route would only be a shift in development procedures, and wouldn't really change things from a user perspective. Alternatives to what I suggest may affect them more strongly. We definitely should CC them when we have a decision, though.
-- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 12, 2015 at 2:55 PM, Sean Busbey <[email protected]> wrote: > oh! almost forgot. We should get user@accumulo into this conversation > sooner rather than later. I'm not sure if it's better ot just copy them in > to this thread or do it as a follow up once we have more of an idea of what > "EOL" means for them. > > On Tue, May 12, 2015 at 1:53 PM, Sean Busbey <[email protected]> wrote: > >> +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 <[email protected]> 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 >> > > > > -- > Sean
