On Monday 22 November 2004 09:11, Bill Stoddard wrote: > > Why drive artificial constraints on any of our release processes? If a > sizeable number of people (ie, a "community") are interested in maintaining > 2.0 for the next 20 years, then why prevent it 'by decree'? >
Id certainly have to agree with this logic. By the standard proposed (6-12 months following new stable release), 1.3 would have been dead, buried, and have a house built on top of it by now. Still, we have recently seen in this very list that there IS a community using 1.3 for various reasons. While I can understand at a certain point scaling back development resources and focus request towards a particular branch, I also believe that no arbitrary EOL cycle should be implemented on a community supported product. There are no real commercial support oblications imcumbant on Apache to continue to provide access and support for patch roll-in for old versions, is there? My own personal $.02 is that EOL should be little more than pulling the status updates from being sent out and not actively requesting backports from 2.x to 1.3.x. Anything beyond that should be driven by community... or lack thereof.... Eventually when no one is supporting the codebase and security issues pile up with warnings on the website and release files that "this is an old version provided for legacy users only. we do not recommend production systems run this version, instead use [insert new branch here]", they will upgrade and 1.3.x (and later 2.0.x) will die a "natural death". If there are coorporate costs involved in legacy version "support" then I can perhaps understand an EOL but with a mostly community-developed and -supported product, I see little reason to introduce an arbitrary limitation on the life of a branch. -- -------------------- Wayne S. Frazee "Any sufficiently developed bug is indistinguishable from a feature."
pgpVsm4ZBmYeU.pgp
Description: PGP signature
