I suppose this will be a problem we will encounter with every major/minor revision as they age, so we have a good chance to hash out a general policy for this.
I see two categories of actions proposed here: 1) Content Changes (e.g: website) 2) SCM Changes (e.g: git repo) As far as 1 is concerned, I have the sense that there's general consensus that we should de-emphasize the 1.4 releases in favor of 1.5 at this point. We could go far in doing this by changing the wording on the website: From: Latest 1.5 release: 1.5.1 Latest 1.4 release: 1.4.5 To something else, perhaps: Current Stable Release: 1.5.1 Legacy Bugfix Release: 1.4.5 I think we also agree that removing Maven artifacts is out of bounds because that will cause breakage for all sorts of things. Mirrors will likely want to drop release tarballs at some point (e.g for old point release versions like 1.4.3, 1.4.4) but I'm not sure how they are signaled to do so. I'm generally in favor of keeping the documentation for old versions around. (E.g: you can still find docs for Lucene 3.0.3 at Apache and it's ancient!) I don't think it makes sense to tag a 1.4.6 release until someone is prepared to follow the release process and produce votable artifacts. At this point I'm hearing that a) work isn't done and b) there isn't sufficient reason to create 1.4.6. I don't think that there is any onus on the Accumulo community to ever produce a 1.4.6 release, but we should not do anything that will prevent that from happening or make it difficult to do so. There are still folks out there that are using 1.4 actively and who knows what darkness lurks at the heart of Accumulo that might need to be fixed. Could someone explain why we would want to ever delete the 1.4.x branch? So, in summary: 1) I agree it makes sense to clearly market 1.5 as the current stable release and market 1.4 as something old that you only want to start using if you're already using. 2) I can't see any good reason to do anything with tags or branches at this point. It is not clear to me why we would want to do anything in SCM to eol 1.4, as long as we cover the website. I'm interested if there are specific mechanical reasons. Drew 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 > > >
