On Wed, Jan 5, 2011 at 11:05 AM, Russell Keith-Magee <
[email protected]> wrote:

> 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.
>
> Any opinions on these two points?
>

The fact that a "security release" includes other fixes does seem to
regularly surprise people. And best efforts at keeping the maintenance
branch regression-free aren't perfect. So I like the idea of security-only
releases.

I assume we would only release a security-fix-only release for the latest
micro release? So say we had 1.2.3, and as you mention simultaneously
release 1.2.3.1 which is security fix only, plus 1.2.4 which also includes
all the bugs fixed since 1.2.3. Then we get another confirmed security issue
to be fixed. We'd release 1.2.4.1 only, not 1.2.3.2 also?

Karen
-- 
http://tracey.org/kmt/

-- 
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.

Reply via email to