On Mon, May 5, 2014 at 3:40 PM, Drew Farris <[email protected]> wrote: > 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)
There is also the impact on ticket workflow. When a version is EOLed, I'd not expect the community to provide any additional fixes for that release line. If 1.4 hangs around, then it creates confusion over what will happen to tickets filed against it. It also will confuse users as they may keep filing 1.4 tickets. > 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: Agreed. > 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 We used to have something like this, but that lead to some arguments over which is stable and which legacy. For example, 1.6.0 is out now so that means that there would be three releases we need to identify. > 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!) Absolutely. We should never delete released artifacts. > 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? I think you want to delete the branch because of our Git workflow[1] which is to always target a patch for the earliest, non-end-of-lifed version. You could argue that the documentation and mailing list announcement are sufficient to declare the branch EOLed, but I don't think that's strong enough for a casual contributor. The purpose of the EOL is to say that the community *won't* create a new 1.4 release. If you need to stick with it for whatever reason, it's expected that you and/or your support vendor will backport required patches and cut your own releases. Nothing here will prevent that. In fact, creating the tag for the work that was in progress on the 1.4 line post the 1.4.5 release should make that easier. > 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. -Joey [1] http://accumulo.apache.org/git.html
