On Tuesday 05 August 2008 13:14:27 Geoffrey Broadwell wrote: > > I can see patching the previous release in case of a critical bugfix, but > > if we get in the habit of encouraging users to expect updates of anything > > older than the previous stable release for free, we've doomed the > > project.
> That's why I was careful to say 'one or more'. As in greater than zero, > but other than that it's a separate policy decision that I was not > trying to address in my previous message. Fair enough. > > Point releases every month. Major releases every three months. > Agree, except I'd like to hear more about how you define a 'major > release'. Deprecation takes one major release. We support the current major release (and possibly the previous major release for critical bugs only). > Half agree. I agree that we should only *directly* support a release > for a limited time, though I think the minimum sane time would be "major > release before current one" -- 3-6 months at any given moment, given > your above schedule. In other words, just because we do a new 3 month > release, doesn't mean we immediately de-support the one we did just 3 > months ago. Right. > Now, I might argue for a longer direct support schedule than just 'most > recent + 1', but I think any less than that can't work in real life. I'm not sure any more of that can work in real life. > Beyond that, I think we need to explicitly acknowledge that distro > packagers have a longer schedule to care about. While we may not > support them directly, we still need to have a process in place to make > sure they are notified about critical problems that may apply to > previous releases, so that they can go back and check/patch their > versions. We should also facilitate any process that will help > different distros to help each other to backport our trunk fixes in a > timely fashion. > > In short, we don't have to do the hard work for the distros ourselves, > but we can't leave them out in the cold, either. I can imagine creating a mailing list for critical update notifications, but hold little hope for support from downstream unless the packager happens to be a contributing member of the project. -- c
