Thanks for the response Joey. It sounds as if there's agreement on a number of points and it sounds like I'm the only person not in favor of deleting the branch and creating a tag a this point. Also, bug management is an interesting issue. Thoughts in-line below:
On Mon, May 5, 2014 at 4:07 PM, Joey Echeverria <[email protected]>wrote: > > 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. > If people find ticket-worthy issues in 1.4 after it's end-of-lifed wouldn't we expect them to file a ticket against that version? Shouldn't these tickets reflect known issues with a release of software that people use? Regardless of the desire of the development community to produce new releases of a specific branch, it is a service to the community of users to be able to record known issues (even if these will ultimately result in a wontfix resolution). Google does a very good job indexing the Apache JIRA. Furthermore, issue reporting activity is a reflection of real-world use which should naturally migrate to future versions, and if people aren't migrating to future versions, we have bigger fish to fry. > 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. > Ok, so, we list three releases instead of two. Two of them happen to be considered stable. If there's confusion in the user community, we likely need to do a better job explaining which one to use a la tomcat [1] Current Stable Releases: 1.5.1, 1.6.0 Legacy Bugfix Release: 1.4.5 > 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. > Who are we trying to protect here? and what are we trying to protect them from? If casual contributors can't keep up with the current state of the code and repository via the mailing list or website, I'd worry either about the quality of their contributions or the quality of the documentation the community is producing in terms of the current state of the project. If folks that would commit to the project aren't aware of where merges should be made I'd worry that they shouldn't be committing to the project in the first place without guidance from the community. So, to summarize: I agree it's time to end of life 1.4 in that I'm in favor of stating clearly that users should not expect new releases of 1.4.x and new projects and migrations should use some other version (preferably 1.6.0) I'm against stating that a new release of 1.4 will >never< be made or must >never< be made - and as a result against deleting the 1.4.x development branch in favor of a tag. I'm also not in favor of preventing people from documenting the issues they find with 1.4 as tickets in jira. Drew [1] http://tomcat.apache.org/whichversion.html
