FWIW, I'm inclined to agree with James and Gabriel that having security
only releases on the bugfix branch will increase confusion, and will
increase the likelihood that human error with regards to packages (both
by the Django team and by Django users) is the cause of both more
security problems an
On Thursday, January 6, 2011 6:29:32 AM UTC-8, James Bennett wrote:
>
> 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.
>
I have the same concern her
On Wed, Jan 5, 2011 at 10:05 AM, Russell Keith-Magee
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
On Wed, Jan 5, 2011 at 1:05 PM, Russell Keith-Magee
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.
>
> This also points out that we sho
On Wed, Jan 5, 2011 at 11:05 AM, Russell Keith-Magee <
russ...@keith-magee.com> 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 th
Hi all,
As I just noted on a blog entry, I've tagged the 1.3 release blocking
bugs in Trac:
http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&keywords=%7Eblocker
Most of these are fairly minor issues. However, there are 5 tickets
that are regressions from 1.2.3 to 1.
