On Wed, Jan 5, 2011 at 10:05 AM, Russell Keith-Magee <[email protected]> wrote: > We will obviously to do a 1.2.5 release when we hit 1.3 final; but I'm > not sure if we should push an 1.2.5 (and 1.1.4) ASAP addressing these > regressions, and then do 1.2.6 when we cut 1.3 final.
I'm in favor of doing 1.2.5 as soon as we know we've fixed the regressions. > This also points out that we should perhaps reconsider our release > policy. Putting out security releases that include unrelated fixes is > a bit of a risk. We've been bitten by this in the past, but never this > bad. I would suggest that when security issues arises in 1.2.3, we > should be releaseing 1.2.3.1 rather than 1.2.4. If a security release > coincides with a point release -- as it did when we released 1.3beta1 > -- we should release 1.2.3.1 (to address the security issue) *and* > 1.2.4 (to get the other bugfixes). This will ensure that it is > possible to update production code and get just the security fix, > without any risk of regressions. So, there are two valid use cases here: 1. "I want to run Django X.Y, and periodically get bugfixes for things that weren't caught before the final release". 2. "I want to run Django X.Y and only care about security fixes." Right now we support both, because you can run the release branch, or just cherry-pick and apply the security patches when we release them. This does mean you're no longer running something that's been tagged as a release, of course. So the question, as I see it, is whether we change that around. There are a couple options: 1. Once we cut X.Y, that's it. The resulting release branch will get security updates and no other changes. This will support case (2) above, but not (1). 2. Each release gets *two* branches. One gets full bugfix support, the other only gets security. This means a security fix results in two new packages -- one from the full-bugfix branch and one from the security-only branch, but means people can choose what they want. I don't think either of these actually works, though; option 1 completely cuts off people who want general bugfix support, and since that's a valid use case (and one I'm pretty sure people rely on) we can't do that. Option 2 doesn't cut anybody off, but does create a bit of a confusing maze of packages -- do I want Django 1.2.5? Django 1.2.4.1? Django 1.2.3.2? This would get worse once a release falls into security-only mode and it becomes harder to distinguish the branches from what's going on in them (since they'd both be getting exactly the same updates at that point). It'd also be a major maintenance/bookkeeping headache and, I think, *more* likely to result in us accidentally crossing the streams while trying to keep track of what goes on in which branch. Personally, I'd be in favor of keeping the overall release process as-is -- one release branch, which gets all bugfixes while applicable, plus highlighting the individual security patches as released -- and providing better documentation of what the release branch really is (i.e., not a security-only branch) and how to pull just a security update if that's what you want. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
