[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Python-modules-team] python-django_1.8.18-1~bpo8+1_amd64.changes REJECTED



On Thu, May 25, 2017 at 05:41:39PM +1000, Brian May wrote:
> Ian Campbell <ijc@debian.org> writes:
> 
> > Yet 1.10.x is going to be in Stretch, according to [0]? If users want
> > LTS then why aren't we shipping that in our upcoming stable release
> > (whether its instead of or in addition to the latest release)?
> 
> In general the Django LTS releases occur after on a cycle, several
> months after the Debian Freeze.
> 
> Django 1.11 LTS was released in April 2017 for example. Even if we could
> get Django 1.11 in the freeze, as Raphael Hertzog was suggesting in
> another email, not sure how the release team would feel about this - and
> it would be up to them I think. There may be ways to ease the pain,
> however it would still be up to the release team.
> 
> I seem to recall the same thing happened when Django 1.8 LTS was
> released, Jessie was already in freeze.
> 
> The alternative option is that we use the previous LTS Django
> release. However, that would mean Jessie would still be on Django 1.4,
> which lost upstream support in 2015.
> 
> Similarly, if Stretch was released with 1.8 LTS (yes I know, this is not
> really an option anymore), Django 1.8 will loose support April next year
> - when Stretch is still supported.
> 
> We would basically be releasing Debian with a old LTS version of Django
> that is obsolete before Debian is even released.

So what are you planning for buster?

The options seem to be:
- 1.11 LTS (already released, supported until April 2020), or
- 2.1 non-LTS (released in August 2018, supported until December 2019)

The full freeze of buster is expected to start in December 2018,
so when 2.2 LTS gets released in April 2019 buster is expected
to be just a few weeks away from being released.

It is pretty obvious that this makes 2.2 LTS a non-option for buster.

I fully agree that neither option is nice, but you have to make that 
decision for buster.

stable is supposed to be stable and backports a workaround when a user
has a good reason for cherry-picking packages from the next stable.

If stable contains the non-LTS version that is less popular in your 
ecosystem and backports contains the more popular LTS, then that's
not how it is supposed to be.

One positive aspect of "old LTS version":

Django 1.11 will be eligible for stretch-backports one or few weeks 
after the release of stretch.

With the "1.11 LTS in buster" option, a user upgrading to 1.11 from 
stretch-backports will get up to 7 years security support for 1.11
from Debian.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


Reply to: