We hashed this out in IRC, and I think it's a fair compromise that is less confusing to users building from an SCM tag.
Some other options proposed, but not deliberated: 1.4-orphaned or 1.4-closeout, or 1.4-abandoned And one other, I just thought of: 1.4-unreleased (or some combination of these) Also noted on the IRC: it may become annoying to continue this practice and have SCM tags full of unreleased and abandoned branches. One final note: this represents a change in precedence... previously all persisted tags have been released versions. This is a change from that practice. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Mon, May 5, 2014 at 3:57 PM, Sean Busbey <[email protected]> wrote: > How about the tag name > > 1.4-development-closed > > This clearly indicates > > * that it's the major version 1.4 (which should limit our ratio of > closed-branches to total tags) > * that it's not a release > * reasonably well that it's the end of a development branch without an > explanation on the website > > -Sean > > On Mon, May 5, 2014 at 2:38 PM, Christopher <[email protected]> wrote: > >> I elaborated above, but in short, all previous tags have indicated >> releases. This is standard to publish tags in SCM to denote a release. >> it's confusing to have a tag that does not denote a release. Further, >> having a version that is greater than the greatest approved release >> may mislead people who build from source to use the "latest", thinking >> it was approved and it wasn't. >> >> -- >> Christopher L Tubbs II >> http://gravatar.com/ctubbsii >> >> >> On Mon, May 5, 2014 at 3:22 PM, Joey Echeverria >> <[email protected]> wrote: >> > The tag tells users where development on the branch ended. Can you >> elaborate on what is confusing about that?-- >> > Joey Echeverria >> > Chief Architect >> > Cloudera Government Solutions >> > >> > On Mon, May 5, 2014 at 3:01 PM, Keith Turner <[email protected]> wrote: >> > >> >> -1 >> >> I am opposed to the tag, because I think what it communicates to users >> is >> >> confusing. I'm in favor of what Christopher suggested. >> >> I was undecided about the general concept of 1.4 EOL, I am still >> working >> >> w/ some users who are still using 1.4 in the short term. Should they >> run >> >> into a serious bug, we will very likely fix it. I discussed this >> situation >> >> w/ Christopher and he suggested if this situation were to occur we could >> >> simply post a patch jira. That plan sounds good w/ me and makes me >> >> comfortable w/ 1.4 EOL now. >> >> On Sat, May 3, 2014 at 4:41 PM, Sean Busbey <[email protected]> >> wrote: >> >>> Accumulo Folks, >> >>> >> >>> I would like to declare end of life for the 1.4 branch of development. >> It's >> >>> been active for a little over two years and the release of 1.6.0 means >> we >> >>> now have three active releases. >> >>> >> >>> Declaring end of life would mean >> >>> >> >>> * Posting an ANNOUNCE message to the user list >> >>> * No longer accepting issue fix version targets for future 1.4 releases >> >>> * Removing fix version targets of 1.4.x for existing open issues >> >>> * The end of having a long lived 1.4 related branch in git >> >>> * Removing direct references to 1.4.x releases on our download page >> >>> * No longer linking to the 1.4 related documentation from the main >> >>> navigation area >> >>> >> >>> Our issue tracker shows that candidate version 1.4.6 currently has: >> >>> >> >>> * 9 closed issues, none of which are blockers or critical. >> >>> * 1 issue in patch available status, marked critical >> >>> * 18 open issues with a target fix version of 1.4.6, four of which are >> >>> marked critical. >> >>> >> >>> Because there is existing work, but not yet enough to warrant a >> release, I >> >>> propose >> >>> that on successful passing of this vote we create a "1.4.6-eol" tag >> with >> >>> the then >> >>> current state of the development branch. >> >>> >> >>> Please vote >> >>> >> >>> [ ] +1 I am in favor of announcing End of Life according to the above >> plan >> >>> [ ] +-0 I am indifferent >> >>> [ ] -1 I am opposed to the above End of Life plan because... >> >>> >> >>> I'm treating this like a release vote. Thus, it will be handled with >> >>> Majority Approval: >> >>> to pass it will need 3 committers to +1 and more committers voting +1 >> than >> >>> -1. >> >>> >> >>> Vote will remain open for 72 hours, until Tuesday, May 6 2014, 20:40 >> UTC >> >>> >> >>> -- >> >>> Sean >> >>> >> > > > > -- > Sean
