Re: Pre-DEP: community support of unmaintained versions of Django

[Christian Hammond]

On Mon, Aug 24, 2015 at 9:32 PM, Ryan Hiebert  wrote:

>
> > On Aug 24, 2015, at 5:37 PM, Carl Meyer  wrote:
> >
> >> Any ideas on alternative ways to tackle this? I'm officially stuck.
> >
> > I'm afraid I don't have any solution to offer, other than embracing the
> > "abstract vs concrete" dependencies distinction, and accepting the fact
> > that users of your wheels/eggs are choosing to be more "on their own"
> > when it comes to their chosen dependency versions.
>
> I definitely agree. setup.py files, for the reason you mentioned, are not
> intended for concrete dependencies, while requirements.txt files are. They
> are the right tool for the job. If I was you, that's what I would do.


That sort of setup works fine when it's a standalone install on a server
that someone experienced with the Python world is maintaining, or a
developer working against a set of modules. It's not really an option for a
full-blown application meant to be easily installed by people used to being
able to run 'apt-get install ' or 'yum install '

As a more complex webapp, our packaging requires the
compilation/minification of .less/.js files, which means any user using the
sdist would need a suitable build environment. That raises a huge barrier
to installation for a significant chunk of our userbase. Our goal is to
keep installation simple for everyone, treating it much like any typical
application, without requiring a whole bunch of pre-setup. Aside from this
particular issue with the backported Django builds, we've been able to do
this for years.

It's basically the difference between being able to download/install a
setup.exe for OpenOffice as opposed to needing a build environment and
source to install it.

It's starting to sound like the best bet for us is to move away from
pip/easy_install for end-user consumption of the software and onto more of
a dedicated installer that can manage dependencies more explicitly, maybe
taking care of the building/consumption of a requirements.txt for them.

Thanks for your thoughts on this, everyone :)

Christian

-- 
Christian Hammond - chip...@chipx86.com
Review Board - https://www.reviewboard.org
Beanbag, Inc. - https://www.beanbaginc.com




>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/69fOquu8v-U/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/486DA079-7F97-4597-A7FB-CD179DFB54DC%40ryanhiebert.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHfcSbxkQaUW6HvLGrTpcZEyrAZGAvgidHHELHOK8-XgCje0zg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pre-DEP: community support of unmaintained versions of Django

[Ryan Hiebert]

> On Aug 24, 2015, at 5:37 PM, Carl Meyer  wrote:
> 
>> Any ideas on alternative ways to tackle this? I'm officially stuck.
> 
> I'm afraid I don't have any solution to offer, other than embracing the
> "abstract vs concrete" dependencies distinction, and accepting the fact
> that users of your wheels/eggs are choosing to be more "on their own"
> when it comes to their chosen dependency versions.

I definitely agree. setup.py files, for the reason you mentioned, are not 
intended for concrete dependencies, while requirements.txt files are. They are 
the right tool for the job. If I was you, that's what I would do.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/486DA079-7F97-4597-A7FB-CD179DFB54DC%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pre-DEP: community support of unmaintained versions of Django

[Carl Meyer]

Hi Christian,

On 08/24/2015 03:52 PM, Christian Hammond wrote:
> pip's removed support for dependency_links, requiring that all package
> dependencies be made available on PyPI. This means there's no way we can
> host a build of this ourselves, have a project depend on it, and build
> the project as a package. It simply will ignore our builds and fail with
> a dependency error (assuming a version range of >=1.6.11.1,<1.7). (If
> installing from source, it looks like requirements.txt can still specify
> links, but that doesn't help when building/distributing wheels/eggs.)

Yes, I'm afraid you're trying to solve an additional problem I didn't
realize you had, because I didn't realize ReviewBoard was distributed as
wheels/eggs.

In general, my feeling has been that Python packaging is not well suited
to distributing deployable web apps, and they are better distributed as
source (with requirements.txt) plus installation instructions. I think
pip's developers feel similarly, and are aiming for a clear distinction
between setup.py "abstract" dependencies and requirements.txt "concrete"
ones. (See e.g. https://caremad.io/2013/07/setup-vs-requirement/,
authored by Donald Stufft, the primary pip maintainer.)

So the official line is that if you need to get _that_ specific about
dependency versions (and especially if you're needing to source those
versions off-PyPI), you should be distributing a requirements.txt file,
not a wheel or an egg.

Obviously there's nothing stopping you from doing that -- just have your
ReviewBoard setup.py depend on ``Django>=1.6,<1.7``, and then strongly
recommend to your clients that they have a ``requirements.txt`` file
with a ``--find-links`` line referencing your Django 1.6 unofficial
support downloads page in order to get the latest security-patched
versions. But that doesn't allow you to automatically enforce that all
the consumers of your wheels/eggs will actually do this.

[snip non-functional workaround]
> The only other option I can think of is to actually upload the 1.6.11.x
> build to PyPI under a different name ("beanbag-django16", for instance),
> but keep the top-level module as "django". This will inevitably cause
> conflicts with the officially installed Django package, though. Not a
> good option.

Nope, not great.

> So at this point, it seems that while we can maintain security backports
> of Django 1.6.11, we can't realistically depend on them or trigger
> upgrading to them. Short of the official Django package on PyPI either
> hosting our backports or registering URLs to them, there might not be a
> clean way to do this. I'm pretty sure is not the route you guys want to
> go for this, though.

I don't really think that's an option. At that point they'd have to be
officially supported, because there's no longer any opt-in required to
get them.

> Any ideas on alternative ways to tackle this? I'm officially stuck.

I'm afraid I don't have any solution to offer, other than embracing the
"abstract vs concrete" dependencies distinction, and accepting the fact
that users of your wheels/eggs are choosing to be more "on their own"
when it comes to their chosen dependency versions.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55DB9CAA.3090108%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Pre-DEP: community support of unmaintained versions of Django

[Christian Hammond]

On Wed, Aug 19, 2015 at 4:43 PM, Markus Holtermann  wrote:

> Hey Christian,
>
> On Wed, Aug 19, 2015 at 02:41:49PM -0700, Christian Hammond wrote:
>
>> Regarding the version number, from what I've read, there's still a
>> reported
>> compatibility issue if we use the +localidentifer part of a version number
>> with older versions of setuptools. I need to do some testing on this. If I
>> don't hit any issues, I'm very happy to put an identifier on there. I
>> would
>> like to keep it at 1.6.11.x, rather than 1.6.12+, so that it's very clear
>> we're based on upstream Django 1.6.11.
>>
>
> Thanks, that sounds good to me. 1.6.11.x+unofficial if possible,
> otherwise 1.6.11.x


Looks like it's going to have to be 1.6.11.x.

However, I've hit a pretty major stumbling block here.

pip's removed support for dependency_links, requiring that all package
dependencies be made available on PyPI. This means there's no way we can
host a build of this ourselves, have a project depend on it, and build the
project as a package. It simply will ignore our builds and fail with a
dependency error (assuming a version range of >=1.6.11.1,<1.7). (If
installing from source, it looks like requirements.txt can still specify
links, but that doesn't help when building/distributing wheels/eggs.)

I tried a hacky workaround of creating a sdist package that invoked
setuptools to install using dependency_links, and depended on that package
instead. Older versions of pip prior to 7.0 would execute our setup.py and
in turn install our build of Django. However, since pip now converts sdists
to wheels prior to installing, it just skips over dependency_links,
resulting in the original problem.

The only other option I can think of is to actually upload the 1.6.11.x
build to PyPI under a different name ("beanbag-django16", for instance),
but keep the top-level module as "django". This will inevitably cause
conflicts with the officially installed Django package, though. Not a good
option.

So at this point, it seems that while we can maintain security backports of
Django 1.6.11, we can't realistically depend on them or trigger upgrading
to them. Short of the official Django package on PyPI either hosting our
backports or registering URLs to them, there might not be a clean way to do
this. I'm pretty sure is not the route you guys want to go for this, though.

Any ideas on alternative ways to tackle this? I'm officially stuck.

Christian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHfcSbx9nwya7Aw3rnmECBZjE%3DwGW%2BSgzMT1tYo9xfXQgiHYjw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pre-DEP: community support of unmaintained versions of Django

[Markus Holtermann]

Hey Christian,

On Wed, Aug 19, 2015 at 02:41:49PM -0700, Christian Hammond wrote:

Regarding the version number, from what I've read, there's still a reported
compatibility issue if we use the +localidentifer part of a version number
with older versions of setuptools. I need to do some testing on this. If I
don't hit any issues, I'm very happy to put an identifier on there. I would
like to keep it at 1.6.11.x, rather than 1.6.12+, so that it's very clear
we're based on upstream Django 1.6.11.


Thanks, that sounds good to me. 1.6.11.x+unofficial if possible,
otherwise 1.6.11.x


I want HTTPS on this pretty badly, though, so we might try that
approach when we can get to it.


Good :)


To attempt to compensate for this, though, we sign all the builds and
include checksums in both the links and in dedicated .sha256sum files. Not
the best solution, but it's something at least :/


Checksums alone won't provide integrity checks if I can play MITM. Only
(e.g. pgp) signatures will help. But then make sure the key ID is
published on an HTTPS page ;)

/Markus


On Wed, Aug 19, 2015 at 9:08 AM, Carl Meyer  wrote:


Hi Christian,

On 08/18/2015 08:01 PM, Christian Hammond wrote:
[snip]
> Also as a status update, we've started a fork and applied for the
> pre-notification list. I've backported all current security fixes to a
> branch, ensured the test suite passes with flying colors, and have added
> a README detailing everything you've requested. This is all up at
> https://github.com/beanbaginc/django. Let me know if there's anything
> you'd like changed.

One thing was pointed out to me just now -- the downloads page _really_
should use TLS. Any chance you could make that happen?

Carl

--
You received this message because you are subscribed to a topic in the
Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/django-developers/69fOquu8v-U/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/55D4AA04.3090403%40oddbird.net
.
For more options, visit https://groups.google.com/d/optout.



--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHfcSbz%3DN9%2BFduAcSODtTVLEVmbD42Nu_CsiJHAQiXxtU70kCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


--

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20150819234311.GA2502%40pyler.local.
For more options, visit https://groups.google.com/d/optout.


pgphn7ufHtysd.pgp
Description: PGP signature

Re: Pre-DEP: community support of unmaintained versions of Django

[Christian Hammond]

Hey everyone,

Thanks for the quick feedback on this :)

Regarding the version number, from what I've read, there's still a reported
compatibility issue if we use the +localidentifer part of a version number
with older versions of setuptools. I need to do some testing on this. If I
don't hit any issues, I'm very happy to put an identifier on there. I would
like to keep it at 1.6.11.x, rather than 1.6.12+, so that it's very clear
we're based on upstream Django 1.6.11.

As for the downloads page, we're hosting everything on S3, as opposed to a
dedicated host. This is so that our deliverables will be replicated and
still be up if either Amazon or we have some outage. We *can* get HTTPS on
this, using CloudFront, but that uses SNI, meaning only the latest Python
2.7.x releases (and 3.x) would be able to download files from there.

We're looking into an approach that spins up a couple VMs that essentially
wrap S3 with an HTTPS endpoint, but it increases our costs a bit, and we're
just not ready to do that yet. I want HTTPS on this pretty badly, though,
so we might try that approach when we can get to it.

To attempt to compensate for this, though, we sign all the builds and
include checksums in both the links and in dedicated .sha256sum files. Not
the best solution, but it's something at least :/

Christian

-- 
Christian Hammond - chip...@chipx86.com
Review Board - https://www.reviewboard.org
Beanbag, Inc. - https://www.beanbaginc.com

On Wed, Aug 19, 2015 at 9:08 AM, Carl Meyer  wrote:

> Hi Christian,
>
> On 08/18/2015 08:01 PM, Christian Hammond wrote:
> [snip]
> > Also as a status update, we've started a fork and applied for the
> > pre-notification list. I've backported all current security fixes to a
> > branch, ensured the test suite passes with flying colors, and have added
> > a README detailing everything you've requested. This is all up at
> > https://github.com/beanbaginc/django. Let me know if there's anything
> > you'd like changed.
>
> One thing was pointed out to me just now -- the downloads page _really_
> should use TLS. Any chance you could make that happen?
>
> Carl
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/69fOquu8v-U/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/55D4AA04.3090403%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHfcSbz%3DN9%2BFduAcSODtTVLEVmbD42Nu_CsiJHAQiXxtU70kCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pre-DEP: community support of unmaintained versions of Django

[Carl Meyer]

Hi Christian,

On 08/18/2015 08:01 PM, Christian Hammond wrote:
[snip]
> Also as a status update, we've started a fork and applied for the
> pre-notification list. I've backported all current security fixes to a
> branch, ensured the test suite passes with flying colors, and have added
> a README detailing everything you've requested. This is all up at
> https://github.com/beanbaginc/django. Let me know if there's anything
> you'd like changed.

One thing was pointed out to me just now -- the downloads page _really_
should use TLS. Any chance you could make that happen?

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55D4AA04.3090403%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Pre-DEP: community support of unmaintained versions of Django

[Carl Meyer]

On 08/19/2015 09:38 AM, Donald Stufft wrote:
> Do we have any evidence that users will notice a fourth digit and
> will make the mental association that they are not official releases?
> I wouldn’t if I hadn’t read this thread. I mean I don’t actually care
> if they use 1.6.11.x or 1.6.12+, I just don’t think it’s really
> buying anything extra. If you want the version number to contain
> something that says “unofficial” just tack an unofficial local
> version number on the end of whichever solution is picked (so
> 1.6.11.5+unofficial or 1.6.12+unofficial) or whatever.

That's a fair point, and IMO an even better suggestion (tacking on
+something for clarity even though it's not technically needed). If we
do that I don't care much between 1.6.11.x vs 1.6.12+, though I guess I
still slightly lean towards the former, as it doesn't constrain the
Django project's options in the (vanishingly unlikely) scenario that
we'd ever want to release something new in the 1.6.x series.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55D4A44E.5000707%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Pre-DEP: community support of unmaintained versions of Django

[Donald Stufft]

On August 19, 2015 at 11:31:46 AM, Carl Meyer (c...@oddbird.net) wrote:
> On 08/19/2015 09:28 AM, Donald Stufft wrote:
> > On August 19, 2015 at 11:25:55 AM, Carl Meyer (c...@oddbird.net) wrote:
> >> In my ideal world, the version number would help convey unofficial-ness
> >> a bit more strongly, but after re-reading PEP 440 I don't think it
> >> leaves us with any good options. I considered post-releases (e.g.
> >> 1.6.11.post1), but "The use of post-releases to publish maintenance
> >> releases containing actual bug fixes is strongly discouraged." So given
> >> the lack of good options, I'm OK with 1.6.11.x. Anyone else on the core
> >> team have a problem with that?
> >
> >
> > 1.6.11.x should work fine, though I’m confused why not just issue 1.6.12+?
>  
> Because that looks exactly like the version number an official Django
> release would use, and the idea is to be as clear as possible that these
> are not official Django releases. For some users (who don't read READMEs
> etc) the version number is one of the few things we can be pretty sure
> they'll see.
>  
>

Do we have any evidence that users will notice a fourth digit and will make the 
mental association that they are not official releases? I wouldn’t if I hadn’t 
read this thread. I mean I don’t actually care if they use 1.6.11.x or 1.6.12+, 
I just don’t think it’s really buying anything extra. If you want the version 
number to contain something that says “unofficial” just tack an unofficial 
local version number on the end of whichever solution is picked (so 
1.6.11.5+unofficial or 1.6.12+unofficial) or whatever.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/etPan.55d4a2f7.394e58e8.6c62%40Draupnir.home.
For more options, visit https://groups.google.com/d/optout.

Re: Pre-DEP: community support of unmaintained versions of Django

[Marc Tamlyn]

Very happy with 1.6.11.x

On 19 August 2015 at 16:31, Carl Meyer  wrote:

> On 08/19/2015 09:28 AM, Donald Stufft wrote:
> > On August 19, 2015 at 11:25:55 AM, Carl Meyer (c...@oddbird.net) wrote:
> >> In my ideal world, the version number would help convey unofficial-ness
> >> a bit more strongly, but after re-reading PEP 440 I don't think it
> >> leaves us with any good options. I considered post-releases (e.g.
> >> 1.6.11.post1), but "The use of post-releases to publish maintenance
> >> releases containing actual bug fixes is strongly discouraged." So given
> >> the lack of good options, I'm OK with 1.6.11.x. Anyone else on the core
> >> team have a problem with that?
> >
> >
> > 1.6.11.x should work fine, though I’m confused why not just issue
> 1.6.12+?
>
> Because that looks exactly like the version number an official Django
> release would use, and the idea is to be as clear as possible that these
> are not official Django releases. For some users (who don't read READMEs
> etc) the version number is one of the few things we can be pretty sure
> they'll see.
>
> Carl
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/55D4A159.5050605%40oddbird.net
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FR5C3-yafJtAS8o_17OWU4MVHcvfhKqD6ZOiudfGLTPg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pre-DEP: community support of unmaintained versions of Django

[Carl Meyer]

Hi Christian,

On 08/18/2015 08:01 PM, Christian Hammond wrote:
> I know it's been a while since we discussed this, but today's security
> release is the first one that's really affecting our product and we've
> finally got things in shape to be able to start distributing unofficial
> Django security releases (we've also just been swamped since our
> discussion earlier this year).
> 
> I wanted to dig into the versioning scheme just a bit. We tried going
> with local version identifiers, but it turns out these are fairly
> useless...
[snip]
> Given that, what would your feelings be on allowing for 1.6.11.x
> releases? This way we wouldn't take up any possible future versioning
> slots (unlikely as they may be), while being compatible with all
> versions of setuptools, and compatible with specifying version ranges.
> This would still appear solely on our own downloads page and
> announcements, with an appropriate note on them being unofficial builds.

In my ideal world, the version number would help convey unofficial-ness
a bit more strongly, but after re-reading PEP 440 I don't think it
leaves us with any good options. I considered post-releases (e.g.
1.6.11.post1), but "The use of post-releases to publish maintenance
releases containing actual bug fixes is strongly discouraged." So given
the lack of good options, I'm OK with 1.6.11.x. Anyone else on the core
team have a problem with that?

> Also as a status update, we've started a fork and applied for the
> pre-notification list. I've backported all current security fixes to a
> branch, ensured the test suite passes with flying colors, and have added
> a README detailing everything you've requested. This is all up at
> https://github.com/beanbaginc/django. Let me know if there's anything
> you'd like changed.

The README looks great, thanks!

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55D49FEE.80503%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Pre-DEP: community support of unmaintained versions of Django

[Carl Meyer]

On 08/19/2015 09:28 AM, Donald Stufft wrote:
> On August 19, 2015 at 11:25:55 AM, Carl Meyer (c...@oddbird.net) wrote:
>> In my ideal world, the version number would help convey unofficial-ness
>> a bit more strongly, but after re-reading PEP 440 I don't think it
>> leaves us with any good options. I considered post-releases (e.g.
>> 1.6.11.post1), but "The use of post-releases to publish maintenance
>> releases containing actual bug fixes is strongly discouraged." So given
>> the lack of good options, I'm OK with 1.6.11.x. Anyone else on the core
>> team have a problem with that?
> 
> 
> 1.6.11.x should work fine, though I’m confused why not just issue 1.6.12+?

Because that looks exactly like the version number an official Django
release would use, and the idea is to be as clear as possible that these
are not official Django releases. For some users (who don't read READMEs
etc) the version number is one of the few things we can be pretty sure
they'll see.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55D4A159.5050605%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Pre-DEP: community support of unmaintained versions of Django

[Donald Stufft]

On August 19, 2015 at 11:25:55 AM, Carl Meyer (c...@oddbird.net) wrote:
> Hi Christian,
>  
> On 08/18/2015 08:01 PM, Christian Hammond wrote:
> > I know it's been a while since we discussed this, but today's security
> > release is the first one that's really affecting our product and we've
> > finally got things in shape to be able to start distributing unofficial
> > Django security releases (we've also just been swamped since our
> > discussion earlier this year).
> >
> > I wanted to dig into the versioning scheme just a bit. We tried going
> > with local version identifiers, but it turns out these are fairly
> > useless...
> [snip]
> > Given that, what would your feelings be on allowing for 1.6.11.x
> > releases? This way we wouldn't take up any possible future versioning
> > slots (unlikely as they may be), while being compatible with all
> > versions of setuptools, and compatible with specifying version ranges.
> > This would still appear solely on our own downloads page and
> > announcements, with an appropriate note on them being unofficial builds.
>  
> In my ideal world, the version number would help convey unofficial-ness
> a bit more strongly, but after re-reading PEP 440 I don't think it
> leaves us with any good options. I considered post-releases (e.g.
> 1.6.11.post1), but "The use of post-releases to publish maintenance
> releases containing actual bug fixes is strongly discouraged." So given
> the lack of good options, I'm OK with 1.6.11.x. Anyone else on the core
> team have a problem with that?


1.6.11.x should work fine, though I’m confused why not just issue 1.6.12+?

>  
> > Also as a status update, we've started a fork and applied for the
> > pre-notification list. I've backported all current security fixes to a
> > branch, ensured the test suite passes with flying colors, and have added
> > a README detailing everything you've requested. This is all up at
> > https://github.com/beanbaginc/django. Let me know if there's anything
> > you'd like changed.
>  
> The README looks great, thanks!
>  
> Carl
>  
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers  
> (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.  
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/55D49FEE.80503%40oddbird.net.
>   
> For more options, visit https://groups.google.com/d/optout.
>  

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/etPan.55d4a082.245ae313.6c62%40Draupnir.home.
For more options, visit https://groups.google.com/d/optout.

Re: Pre-DEP: community support of unmaintained versions of Django

[Christian Hammond]

Hi Carl,

I know it's been a while since we discussed this, but today's security 
release is the first one that's really affecting our product and we've 
finally got things in shape to be able to start distributing unofficial 
Django security releases (we've also just been swamped since our discussion 
earlier this year).

I wanted to dig into the versioning scheme just a bit. We tried going with 
local version identifiers, but it turns out these are fairly useless. When 
specifying a dependency with a local version identifier, your only option 
is direct equality (==1.6.11+extended.1). You can't use any form of range 
(>=1.6.11+extended.4), as these get interpreted as >=1.6.11. This is the 
case with both easy_install and pip, and is documented in the PEP.

That means consumers of the builds either need to specify an explicit 
version (preventing other packages or administrators from choosing a higher 
version when a new build is released), or need to depend on the official 
1.6.11 and rely on administrators to keep up-to-date with the latest 
releases and manually install them.

Not to mention that this all falls apart if using setuptools < 8, which 
doesn't support these identifiers.

Given that, what would your feelings be on allowing for 1.6.11.x releases? 
This way we wouldn't take up any possible future versioning slots (unlikely 
as they may be), while being compatible with all versions of setuptools, 
and compatible with specifying version ranges. This would still appear 
solely on our own downloads page and announcements, with an appropriate 
note on them being unofficial builds.

Also as a status update, we've started a fork and applied for the 
pre-notification list. I've backported all current security fixes to a 
branch, ensured the test suite passes with flying colors, and have added a 
README detailing everything you've requested. This is all up at 
https://github.com/beanbaginc/django. Let me know if there's anything you'd 
like changed.

Thanks,

Christian


On Friday, March 27, 2015 at 9:25:20 AM UTC-7, Carl Meyer wrote:
>
> Hi John and Christian, 
>
> On 03/27/2015 09:46 AM, John Paulett wrote: 
> > James, thanks for putting this together. 
> > 
> > Christian, I am in a similar position, supporting 2.6 for the next 6-12 
> > months.  I had planned to keep a personal fork of Django 1.6, 
> > backporting security patches as needed, but I would be happy to 
> > contribute to a common effort in this regard. 
> > 
> > As mentioned by others, keeping the effort unofficial may be ideal.  A 
> > planed end-of-life of this secondary support may also be helpful to 
> > still convince people to migrate forward. 
> > 
> > For a personal fork this wasn't going to be needed, but I wonder how 
> > package distribution should occur. I doubt that publishing unofficial 
> > distributable under Django's PyPI project is advisable. 
>
> I agree. 
>
> I'll outline my idea of how this could work; consider it an alternative 
> proposal (or proposed revision of) James' DEP. (I don't think a DEP is 
> needed for this, but if other core team members feel that it is, I am 
> willing to work this up into DEP format). 
>
> - The community support work happens in a third-party GitHub fork. If 
> you and Christian want to work together on it for 1.6, one of you can 
> create a repo and grant the other commit access. (This is of course 
> something that you have every right to do regardless of what the core 
> team thinks of it.) 
>
> - One of you applies for security pre-notifications (under the 
> "distributor of Django" category -- essentially you are applying to be 
> equivalent to e.g. a Debian or Fedora packager of Django, who 
> could/might provide the same kind of extended support you are planning 
> to.) 
>
> - I think from the core team's perspective, the ideal situation would be 
> that these releases not be on PyPI at all, but that your users would 
> download them directly from the "releases" section of your github repo, 
> or perhaps pip-install them from a PyPI-compatible index that you 
> publish somewhere on static file hosting. If this is acceptable, it 
> would allow you to use PEP 440 "local version identifiers" [1] in your 
> versions, which I think is the most semantically correct for this 
> situation. So your versions would look something like 
> "1.6.11+extended-1" (choice of actual local-version label up to you). 
> If not-on-PyPI is a total dealbreaker for your users, it might be an 
> option to release under a different PyPI project name, such as 
> "Django-16-Community-Support" or similar, but this is less than ideal. 
> For one, it would require the actual package to have a name other than 
> "Django", and it would require the use of something like "1.6.11.post1" 
> instead of the local version identifier, since PyPI does not accept 
> local version identifiers. 
>
> - A preamble should be added to the README of the project on GitHub to 
> indicate that this is unofficial community-based 

Re: Pre-DEP: community support of unmaintained versions of Django

[John Paulett]

Carl, your proposal sounds good to me.  I would be happy to contribute to a
DEP, if formalization of the process is necessary.

Christian, let's coordinate to set up a public/private repo pair with the
appropriate warnings and have one of us apply for the pre-release
notifications (if you haven't already).

Personally, I want to ensure we stay true to the core team's wishes. So as
we proceed, please reach out if there is anything we could be doing better,
particularly clarification that this is an unofficial community effort and
encouraging the transition to the official release.

John


On Fri, Mar 27, 2015 at 6:43 PM, Marc Tamlyn  wrote:

> Sounds broadly good to me. I'd be happy for it to be pushed to pypi under
> django-legacy or similar name.
>
> Marc
> On 27 Mar 2015 16:36, "Tim Graham"  wrote:
>
>> Sounds good to me.
>>
>> On Friday, March 27, 2015 at 12:28:09 PM UTC-4, Carl Meyer wrote:
>>>
>>> Hi Christian,
>>>
>>> On 03/26/2015 05:11 PM, Christian Hammond wrote:
>>> > I know you guys are still sorting out how you want to run this, but I
>>> > wanted to let you know that, given our current dependence on Python
>>> 2.6,
>>> > I'm willing to do what's needed to maintain security backports for
>>> > either an official or unofficial fork.
>>> >
>>> > I'd love to know some further thoughts on the logistics for this.
>>> Things
>>> > like how versioning would work, what you'd need from me, what kind of
>>> > timeframes we'd have to work with, any legalese needed to be notified
>>> of
>>> > security issues, etc.
>>>
>>> Tim pointed you to the details for requesting security pre-notification.
>>> We pre-notify a week in advance, so that's the timeframe you'd have
>>> available to get a patch (or patches) prepped to apply to your fork.
>>> Obviously we'd expect that you wouldn't push any patches to a public
>>> fork until the embargo ends with our release announcement; you could
>>> manage that by simply staging patches on a local machine, or by
>>> coordinating patches during the embargo in a private GitHub repo.
>>>
>>> Carl
>>>
>>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/3eaf7467-90bc-41d6-b903-6b3198bd38d2%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMwjO1EizLpYtKMjrshPLn%3DspjuyjtnW04LwEH23v0NyJFckSg%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANRBGvYAiuGQXee6JAJhtnnjiP4zDu8S6c5hYG_hOqz0TfFEig%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pre-DEP: community support of unmaintained versions of Django

[Marc Tamlyn]

Sounds broadly good to me. I'd be happy for it to be pushed to pypi under
django-legacy or similar name.

Marc
On 27 Mar 2015 16:36, "Tim Graham"  wrote:

> Sounds good to me.
>
> On Friday, March 27, 2015 at 12:28:09 PM UTC-4, Carl Meyer wrote:
>>
>> Hi Christian,
>>
>> On 03/26/2015 05:11 PM, Christian Hammond wrote:
>> > I know you guys are still sorting out how you want to run this, but I
>> > wanted to let you know that, given our current dependence on Python
>> 2.6,
>> > I'm willing to do what's needed to maintain security backports for
>> > either an official or unofficial fork.
>> >
>> > I'd love to know some further thoughts on the logistics for this.
>> Things
>> > like how versioning would work, what you'd need from me, what kind of
>> > timeframes we'd have to work with, any legalese needed to be notified
>> of
>> > security issues, etc.
>>
>> Tim pointed you to the details for requesting security pre-notification.
>> We pre-notify a week in advance, so that's the timeframe you'd have
>> available to get a patch (or patches) prepped to apply to your fork.
>> Obviously we'd expect that you wouldn't push any patches to a public
>> fork until the embargo ends with our release announcement; you could
>> manage that by simply staging patches on a local machine, or by
>> coordinating patches during the embargo in a private GitHub repo.
>>
>> Carl
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3eaf7467-90bc-41d6-b903-6b3198bd38d2%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1EizLpYtKMjrshPLn%3DspjuyjtnW04LwEH23v0NyJFckSg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pre-DEP: community support of unmaintained versions of Django

[Tim Graham]

Sounds good to me.

On Friday, March 27, 2015 at 12:28:09 PM UTC-4, Carl Meyer wrote:
>
> Hi Christian, 
>
> On 03/26/2015 05:11 PM, Christian Hammond wrote: 
> > I know you guys are still sorting out how you want to run this, but I 
> > wanted to let you know that, given our current dependence on Python 2.6, 
> > I'm willing to do what's needed to maintain security backports for 
> > either an official or unofficial fork. 
> > 
> > I'd love to know some further thoughts on the logistics for this. Things 
> > like how versioning would work, what you'd need from me, what kind of 
> > timeframes we'd have to work with, any legalese needed to be notified of 
> > security issues, etc. 
>
> Tim pointed you to the details for requesting security pre-notification. 
> We pre-notify a week in advance, so that's the timeframe you'd have 
> available to get a patch (or patches) prepped to apply to your fork. 
> Obviously we'd expect that you wouldn't push any patches to a public 
> fork until the embargo ends with our release announcement; you could 
> manage that by simply staging patches on a local machine, or by 
> coordinating patches during the embargo in a private GitHub repo. 
>
> Carl 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3eaf7467-90bc-41d6-b903-6b3198bd38d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pre-DEP: community support of unmaintained versions of Django

[Carl Meyer]

Hi Christian,

On 03/26/2015 05:11 PM, Christian Hammond wrote:
> I know you guys are still sorting out how you want to run this, but I
> wanted to let you know that, given our current dependence on Python 2.6,
> I'm willing to do what's needed to maintain security backports for
> either an official or unofficial fork.
> 
> I'd love to know some further thoughts on the logistics for this. Things
> like how versioning would work, what you'd need from me, what kind of
> timeframes we'd have to work with, any legalese needed to be notified of
> security issues, etc.

Tim pointed you to the details for requesting security pre-notification.
We pre-notify a week in advance, so that's the timeframe you'd have
available to get a patch (or patches) prepped to apply to your fork.
Obviously we'd expect that you wouldn't push any patches to a public
fork until the embargo ends with our release announcement; you could
manage that by simply staging patches on a local machine, or by
coordinating patches during the embargo in a private GitHub repo.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5515850C.2090307%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Pre-DEP: community support of unmaintained versions of Django

[Carl Meyer]

Hi John and Christian,

On 03/27/2015 09:46 AM, John Paulett wrote:
> James, thanks for putting this together.
> 
> Christian, I am in a similar position, supporting 2.6 for the next 6-12
> months.  I had planned to keep a personal fork of Django 1.6,
> backporting security patches as needed, but I would be happy to
> contribute to a common effort in this regard.
> 
> As mentioned by others, keeping the effort unofficial may be ideal.  A
> planed end-of-life of this secondary support may also be helpful to
> still convince people to migrate forward.
> 
> For a personal fork this wasn't going to be needed, but I wonder how
> package distribution should occur. I doubt that publishing unofficial
> distributable under Django's PyPI project is advisable.

I agree.

I'll outline my idea of how this could work; consider it an alternative
proposal (or proposed revision of) James' DEP. (I don't think a DEP is
needed for this, but if other core team members feel that it is, I am
willing to work this up into DEP format).

- The community support work happens in a third-party GitHub fork. If
you and Christian want to work together on it for 1.6, one of you can
create a repo and grant the other commit access. (This is of course
something that you have every right to do regardless of what the core
team thinks of it.)

- One of you applies for security pre-notifications (under the
"distributor of Django" category -- essentially you are applying to be
equivalent to e.g. a Debian or Fedora packager of Django, who
could/might provide the same kind of extended support you are planning to.)

- I think from the core team's perspective, the ideal situation would be
that these releases not be on PyPI at all, but that your users would
download them directly from the "releases" section of your github repo,
or perhaps pip-install them from a PyPI-compatible index that you
publish somewhere on static file hosting. If this is acceptable, it
would allow you to use PEP 440 "local version identifiers" [1] in your
versions, which I think is the most semantically correct for this
situation. So your versions would look something like
"1.6.11+extended-1" (choice of actual local-version label up to you).
If not-on-PyPI is a total dealbreaker for your users, it might be an
option to release under a different PyPI project name, such as
"Django-16-Community-Support" or similar, but this is less than ideal.
For one, it would require the actual package to have a name other than
"Django", and it would require the use of something like "1.6.11.post1"
instead of the local version identifier, since PyPI does not accept
local version identifiers.

- A preamble should be added to the README of the project on GitHub to
indicate that this is unofficial community-based extended support for
Django 1.6, intended only for users of distributions who are providing
extended security support for Python 2.6, and should only be used under
those circumstances. It should clearly warn that Python 2.6 is EOL and
should not be used unless your distro is continuing to support it. It
should also clearly indicate that the Django core team is not providing
this extended support, and point to the correct GitHub repo issues
tracker for raising any issues with it. The same information should be
provided in public announcements about the extended support, web pages
about it, etc.

How does this sound to you, Christian and John?

How does it sound to other members of the core team? Any objections to
any of what I proposed?

Thanks,

Carl

  [1] https://www.python.org/dev/peps/pep-0440/#local-version-identifiers

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55158459.9040304%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Pre-DEP: community support of unmaintained versions of Django

[John Paulett]

James, thanks for putting this together.

Christian, I am in a similar position, supporting 2.6 for the next 6-12
months.  I had planned to keep a personal fork of Django 1.6, backporting
security patches as needed, but I would be happy to contribute to a common
effort in this regard.

As mentioned by others, keeping the effort unofficial may be ideal.  A
planed end-of-life of this secondary support may also be helpful to still
convince people to migrate forward.

For a personal fork this wasn't going to be needed, but I wonder how
package distribution should occur. I doubt that publishing unofficial
distributable under Django's PyPI project is advisable.

John



On Fri, Mar 27, 2015 at 10:06 AM, Tim Graham  wrote:

> Instructions for requesting to be added to the security prenotification
> list are here:
> https://docs.djangoproject.com/en/dev/internals/security/#requesting-notifications
>
>
> On Thursday, March 26, 2015 at 7:11:12 PM UTC-4, Christian Hammond wrote:
>>
>> Hi Carl, James,
>>
>> Sorry for the late reply on this. I've been unavailable the past week.
>>
>> I know you guys are still sorting out how you want to run this, but I
>> wanted to let you know that, given our current dependence on Python 2.6,
>> I'm willing to do what's needed to maintain security backports for either
>> an official or unofficial fork.
>>
>> I'd love to know some further thoughts on the logistics for this. Things
>> like how versioning would work, what you'd need from me, what kind of
>> timeframes we'd have to work with, any legalese needed to be notified of
>> security issues, etc.
>>
>> Thanks!
>>
>> Christian
>>
>>
>> On Friday, March 20, 2015 at 10:02:40 AM UTC-7, Carl Meyer wrote:
>>>
>>> Hi James,
>>>
>>> Thanks for taking the time to write this up carefully, research the
>>> history, etc. I think some form of extended community-based support
>>> could work, but I have some concerns about your specific proposal;
>>> mostly, that it places too much of the responsibility with the core
>>> team.
>>>
>>> My feeling is that we don't really need a DEP or this much process
>>> specified at this point; it'd be plenty for now to simply express
>>> guarded openness to the idea of extended community maintenance for 1.6
>>> and/or 1.4 and see if anyone actually steps up to do the work.
>>>
>>> I'm also curious how this sounds to Christian and Stephen, who asked for
>>> the extended support on django-users. Since they're the only ones who
>>> have asked, if a proposal along these lines won't work for their cases,
>>> then there's not much point in going forward with it.
>>>
>>> Comments interspersed:
>>>
>>> On 03/19/2015 04:59 PM, James Bennett wrote:
>>> > There's been some recent discussion in a django-users thread[1] about
>>> > the impending end-of-life of Django 1.6, which in turn will mean
>>> > end-of-life for Django supported on Python 2.6. In addition, the
>>> > end-of-life of the current LTS release, Django 1.4, will mean
>>> > end-of-life for Django supported on Python 2.5. The following is a
>>> > draft of a proposal based on ideas raised in that thread; it should be
>>> > considered pre-DEP status, to be elevated to a DEP submission if there
>>> > is sufficient support.
>>> >
>>> >
>>> > Abstract
>>> > 
>>> >
>>> > The support process for older versions of Django is changed, as
>>> > follows:
>>> >
>>> > * Official support for older versions of Django from the Django core
>>> >   team will continue to end at the scheduled times (i.e., upon release
>>> >   of a new minor version for non-LTS releases, at end of advertised
>>> >   support lifetime for LTS releases).
>>> >
>>> > * Unofficial support, by persons willing to volunteer their time, will
>>> >   be permitted through a secondary code repository existing solely to
>>> >   provide this support.
>>>
>>> "Permitted" sounds odd to me, since regardless of this DEP I don't think
>>> the core team is in a position to forbid anyone else from continuing to
>>> patch older Django releases if they want to. (I suppose if we really
>>> wanted to we could prevent them from using the Django trademark to
>>> describe what they are doing, but IANAL.)
>>>
>>> I'm also not convinced we should provide a special repo under the
>>> django/ org for this. That doesn't bring any technical benefits, just
>>> social ones (perception of "officialness"). And I'm not clear that
>>> perception of officialness is a good thing - after all, this support is
>>> unofficial. So I would lean towards saying that this concept should be
>>> well-proven in a third-party repo (created by whoever is doing the work)
>>> before we even consider a django/ repo for it.
>>>
>>> > * As the official end-of-life of each Django version approaches, the
>>> >   Django core team will solicit proposals and volunteers to provide
>>> >   unofficial support for that version past its official end-of-life,
>>> >   and select maintainer(s) from amongst those volunteers. This support
>>> 

Re: Pre-DEP: community support of unmaintained versions of Django

[Tim Graham]

Instructions for requesting to be added to the security prenotification 
list are here: 
https://docs.djangoproject.com/en/dev/internals/security/#requesting-notifications

On Thursday, March 26, 2015 at 7:11:12 PM UTC-4, Christian Hammond wrote:
>
> Hi Carl, James,
>
> Sorry for the late reply on this. I've been unavailable the past week.
>
> I know you guys are still sorting out how you want to run this, but I 
> wanted to let you know that, given our current dependence on Python 2.6, 
> I'm willing to do what's needed to maintain security backports for either 
> an official or unofficial fork.
>
> I'd love to know some further thoughts on the logistics for this. Things 
> like how versioning would work, what you'd need from me, what kind of 
> timeframes we'd have to work with, any legalese needed to be notified of 
> security issues, etc.
>
> Thanks!
>
> Christian
>
>
> On Friday, March 20, 2015 at 10:02:40 AM UTC-7, Carl Meyer wrote:
>>
>> Hi James, 
>>
>> Thanks for taking the time to write this up carefully, research the 
>> history, etc. I think some form of extended community-based support 
>> could work, but I have some concerns about your specific proposal; 
>> mostly, that it places too much of the responsibility with the core team. 
>>
>> My feeling is that we don't really need a DEP or this much process 
>> specified at this point; it'd be plenty for now to simply express 
>> guarded openness to the idea of extended community maintenance for 1.6 
>> and/or 1.4 and see if anyone actually steps up to do the work. 
>>
>> I'm also curious how this sounds to Christian and Stephen, who asked for 
>> the extended support on django-users. Since they're the only ones who 
>> have asked, if a proposal along these lines won't work for their cases, 
>> then there's not much point in going forward with it. 
>>
>> Comments interspersed: 
>>
>> On 03/19/2015 04:59 PM, James Bennett wrote: 
>> > There's been some recent discussion in a django-users thread[1] about 
>> > the impending end-of-life of Django 1.6, which in turn will mean 
>> > end-of-life for Django supported on Python 2.6. In addition, the 
>> > end-of-life of the current LTS release, Django 1.4, will mean 
>> > end-of-life for Django supported on Python 2.5. The following is a 
>> > draft of a proposal based on ideas raised in that thread; it should be 
>> > considered pre-DEP status, to be elevated to a DEP submission if there 
>> > is sufficient support. 
>> > 
>> > 
>> > Abstract 
>> >  
>> > 
>> > The support process for older versions of Django is changed, as 
>> > follows: 
>> > 
>> > * Official support for older versions of Django from the Django core 
>> >   team will continue to end at the scheduled times (i.e., upon release 
>> >   of a new minor version for non-LTS releases, at end of advertised 
>> >   support lifetime for LTS releases). 
>> > 
>> > * Unofficial support, by persons willing to volunteer their time, will 
>> >   be permitted through a secondary code repository existing solely to 
>> >   provide this support. 
>>
>> "Permitted" sounds odd to me, since regardless of this DEP I don't think 
>> the core team is in a position to forbid anyone else from continuing to 
>> patch older Django releases if they want to. (I suppose if we really 
>> wanted to we could prevent them from using the Django trademark to 
>> describe what they are doing, but IANAL.) 
>>
>> I'm also not convinced we should provide a special repo under the 
>> django/ org for this. That doesn't bring any technical benefits, just 
>> social ones (perception of "officialness"). And I'm not clear that 
>> perception of officialness is a good thing - after all, this support is 
>> unofficial. So I would lean towards saying that this concept should be 
>> well-proven in a third-party repo (created by whoever is doing the work) 
>> before we even consider a django/ repo for it. 
>>
>> > * As the official end-of-life of each Django version approaches, the 
>> >   Django core team will solicit proposals and volunteers to provide 
>> >   unofficial support for that version past its official end-of-life, 
>> >   and select maintainer(s) from amongst those volunteers. This support 
>> >   will be known as "community maintenance". 
>>
>> This is my strongest objection to the proposal. This whole scheme will 
>> only work if the community maintainer is highly motivated, and there's a 
>> strong need for the extended community maintenance for a specific 
>> release. One indicator of both is that the initiative comes unsolicited 
>> from the community. I think it makes sense to clarify our general 
>> openness to such initiative, but I'm opposed to adding an additional 
>> responsibility to the core team's plate to "solicit proposals and 
>> volunteers" for community maintenance of every release that hits EOL. 
>>
>> > Rationale 
>> > - 
>> > 
>> > For the past five years, Django has been in the process of deprecating 
>> > support for older 2.x 

Re: Pre-DEP: community support of unmaintained versions of Django

[Christian Hammond]

Hi Carl, James,

Sorry for the late reply on this. I've been unavailable the past week.

I know you guys are still sorting out how you want to run this, but I 
wanted to let you know that, given our current dependence on Python 2.6, 
I'm willing to do what's needed to maintain security backports for either 
an official or unofficial fork.

I'd love to know some further thoughts on the logistics for this. Things 
like how versioning would work, what you'd need from me, what kind of 
timeframes we'd have to work with, any legalese needed to be notified of 
security issues, etc.

Thanks!

Christian


On Friday, March 20, 2015 at 10:02:40 AM UTC-7, Carl Meyer wrote:
>
> Hi James, 
>
> Thanks for taking the time to write this up carefully, research the 
> history, etc. I think some form of extended community-based support 
> could work, but I have some concerns about your specific proposal; 
> mostly, that it places too much of the responsibility with the core team. 
>
> My feeling is that we don't really need a DEP or this much process 
> specified at this point; it'd be plenty for now to simply express 
> guarded openness to the idea of extended community maintenance for 1.6 
> and/or 1.4 and see if anyone actually steps up to do the work. 
>
> I'm also curious how this sounds to Christian and Stephen, who asked for 
> the extended support on django-users. Since they're the only ones who 
> have asked, if a proposal along these lines won't work for their cases, 
> then there's not much point in going forward with it. 
>
> Comments interspersed: 
>
> On 03/19/2015 04:59 PM, James Bennett wrote: 
> > There's been some recent discussion in a django-users thread[1] about 
> > the impending end-of-life of Django 1.6, which in turn will mean 
> > end-of-life for Django supported on Python 2.6. In addition, the 
> > end-of-life of the current LTS release, Django 1.4, will mean 
> > end-of-life for Django supported on Python 2.5. The following is a 
> > draft of a proposal based on ideas raised in that thread; it should be 
> > considered pre-DEP status, to be elevated to a DEP submission if there 
> > is sufficient support. 
> > 
> > 
> > Abstract 
> >  
> > 
> > The support process for older versions of Django is changed, as 
> > follows: 
> > 
> > * Official support for older versions of Django from the Django core 
> >   team will continue to end at the scheduled times (i.e., upon release 
> >   of a new minor version for non-LTS releases, at end of advertised 
> >   support lifetime for LTS releases). 
> > 
> > * Unofficial support, by persons willing to volunteer their time, will 
> >   be permitted through a secondary code repository existing solely to 
> >   provide this support. 
>
> "Permitted" sounds odd to me, since regardless of this DEP I don't think 
> the core team is in a position to forbid anyone else from continuing to 
> patch older Django releases if they want to. (I suppose if we really 
> wanted to we could prevent them from using the Django trademark to 
> describe what they are doing, but IANAL.) 
>
> I'm also not convinced we should provide a special repo under the 
> django/ org for this. That doesn't bring any technical benefits, just 
> social ones (perception of "officialness"). And I'm not clear that 
> perception of officialness is a good thing - after all, this support is 
> unofficial. So I would lean towards saying that this concept should be 
> well-proven in a third-party repo (created by whoever is doing the work) 
> before we even consider a django/ repo for it. 
>
> > * As the official end-of-life of each Django version approaches, the 
> >   Django core team will solicit proposals and volunteers to provide 
> >   unofficial support for that version past its official end-of-life, 
> >   and select maintainer(s) from amongst those volunteers. This support 
> >   will be known as "community maintenance". 
>
> This is my strongest objection to the proposal. This whole scheme will 
> only work if the community maintainer is highly motivated, and there's a 
> strong need for the extended community maintenance for a specific 
> release. One indicator of both is that the initiative comes unsolicited 
> from the community. I think it makes sense to clarify our general 
> openness to such initiative, but I'm opposed to adding an additional 
> responsibility to the core team's plate to "solicit proposals and 
> volunteers" for community maintenance of every release that hits EOL. 
>
> > Rationale 
> > - 
> > 
> > For the past five years, Django has been in the process of deprecating 
> > support for older 2.x release of Python, as part of a plan to move 
> > Django toward, first, compatibility with both Python 2 and Python 3 
> > (completed as of Django 1.6), and ultimately with only Python 3 (in a 
> > future, to-be-determined, release). 
> > 
> > The timeline for this was as follows: 
> > 
> > * May 2010: Django 1.2 instituted a minimum Python version of 2.4. 
> > 
> > 

Re: Pre-DEP: community support of unmaintained versions of Django

[Aymeric Augustin]

Hi James,

When I read your proposal I thought -- "this makes sense, but if maintainers
are making this commitment, they should be part of the Django team".

Only after reading Carl's comment did I realize that they shouldn't be part
of
the team in order to keep the "unofficial" aspect.

This makes me think that you've drawn the line too close to official
extended
support.

Otherwise I'm +0 on the general concept, mostly because I'm lucky enough to
care about Python 3.4 only ;-)

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANE-7mX75eaq3c4w3BFTVUhNEOcTUAGNo-z88z2L4b7ZCY1MwA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pre-DEP: community support of unmaintained versions of Django

[Carl Meyer]

Hi James,

Thanks for taking the time to write this up carefully, research the
history, etc. I think some form of extended community-based support
could work, but I have some concerns about your specific proposal;
mostly, that it places too much of the responsibility with the core team.

My feeling is that we don't really need a DEP or this much process
specified at this point; it'd be plenty for now to simply express
guarded openness to the idea of extended community maintenance for 1.6
and/or 1.4 and see if anyone actually steps up to do the work.

I'm also curious how this sounds to Christian and Stephen, who asked for
the extended support on django-users. Since they're the only ones who
have asked, if a proposal along these lines won't work for their cases,
then there's not much point in going forward with it.

Comments interspersed:

On 03/19/2015 04:59 PM, James Bennett wrote:
> There's been some recent discussion in a django-users thread[1] about
> the impending end-of-life of Django 1.6, which in turn will mean
> end-of-life for Django supported on Python 2.6. In addition, the
> end-of-life of the current LTS release, Django 1.4, will mean
> end-of-life for Django supported on Python 2.5. The following is a
> draft of a proposal based on ideas raised in that thread; it should be
> considered pre-DEP status, to be elevated to a DEP submission if there
> is sufficient support.
> 
> 
> Abstract
> 
> 
> The support process for older versions of Django is changed, as
> follows:
> 
> * Official support for older versions of Django from the Django core
>   team will continue to end at the scheduled times (i.e., upon release
>   of a new minor version for non-LTS releases, at end of advertised
>   support lifetime for LTS releases).
> 
> * Unofficial support, by persons willing to volunteer their time, will
>   be permitted through a secondary code repository existing solely to
>   provide this support.

"Permitted" sounds odd to me, since regardless of this DEP I don't think
the core team is in a position to forbid anyone else from continuing to
patch older Django releases if they want to. (I suppose if we really
wanted to we could prevent them from using the Django trademark to
describe what they are doing, but IANAL.)

I'm also not convinced we should provide a special repo under the
django/ org for this. That doesn't bring any technical benefits, just
social ones (perception of "officialness"). And I'm not clear that
perception of officialness is a good thing - after all, this support is
unofficial. So I would lean towards saying that this concept should be
well-proven in a third-party repo (created by whoever is doing the work)
before we even consider a django/ repo for it.

> * As the official end-of-life of each Django version approaches, the
>   Django core team will solicit proposals and volunteers to provide
>   unofficial support for that version past its official end-of-life,
>   and select maintainer(s) from amongst those volunteers. This support
>   will be known as "community maintenance".

This is my strongest objection to the proposal. This whole scheme will
only work if the community maintainer is highly motivated, and there's a
strong need for the extended community maintenance for a specific
release. One indicator of both is that the initiative comes unsolicited
from the community. I think it makes sense to clarify our general
openness to such initiative, but I'm opposed to adding an additional
responsibility to the core team's plate to "solicit proposals and
volunteers" for community maintenance of every release that hits EOL.

> Rationale
> -
> 
> For the past five years, Django has been in the process of deprecating
> support for older 2.x release of Python, as part of a plan to move
> Django toward, first, compatibility with both Python 2 and Python 3
> (completed as of Django 1.6), and ultimately with only Python 3 (in a
> future, to-be-determined, release).
> 
> The timeline for this was as follows:
> 
> * May 2010: Django 1.2 instituted a minimum Python version of 2.4.
> 
> * March 2011: Django 1.3 was the final release to support Python 2.4.
> 
> * March 2012: Django 1.4 (LTS) raised the minimum Python version to
>   2.5, and was the final release to support Python 2.5.
> 
> * February 2013: Django 1.5 raised the minimum Python version to 2.6.
> 
> * November 2013: Django 1.6 was the final release to support Python
>   2.6.
> 
> * September 2014: Django 1.7 raised the minimum Python version to 2.7.
> 
> * Late Q1/early Q2 2015: Django 1.4 and Django 1.6 will reach
>   end-of-life (the former on a scheduled date, the latter upon the
>   release of Django 1.8).
> 
> While this process was necessary to achieve at least a minimum of
> Python 2.6 (the lowest version enabling compatibility with Python 2
> and Python 3 in a single codebase) and ultimately a minimum of Python
> 2.7 (the only Python 2.x release still receiving upstream security
> support), and while 

Re: Pre-DEP: community support of unmaintained versions of Django

[Collin Anderson]

Hi All,

I am free of 2.6 websites myself (and nearly free of 2.x completely), but I 
think this makes sense and I'm certainly in favor of community-maintained 
longer support periods of django versions, assuming people want to do it :)

Two thoughts:

- This doesn't _need_ to happen through Django officially, but doing it 
this way has the advantage of receiving pre-notify and the having some of 
Django's blessing gives more confidence to anyone using it.

- I'm not saying anyone wants this, but I could also see the possibility of 
volunteers wanting to continue 1.4's support on 2.6 and 2.7 only (dropping 
2.5 support).

If it helps, I have the historical Python support in table form:
https://gist.github.com/collinanderson/3597ec51a7d2f1092eb5

Collin

On Thursday, March 19, 2015 at 6:59:59 PM UTC-4, James Bennett wrote:
>
> There's been some recent discussion in a django-users thread[1] about
> the impending end-of-life of Django 1.6, which in turn will mean
> end-of-life for Django supported on Python 2.6. In addition, the
> end-of-life of the current LTS release, Django 1.4, will mean
> end-of-life for Django supported on Python 2.5. The following is a
> draft of a proposal based on ideas raised in that thread; it should be
> considered pre-DEP status, to be elevated to a DEP submission if there
> is sufficient support.
>
>
> Abstract
> 
>
> The support process for older versions of Django is changed, as
> follows:
>
> * Official support for older versions of Django from the Django core
>   team will continue to end at the scheduled times (i.e., upon release
>   of a new minor version for non-LTS releases, at end of advertised
>   support lifetime for LTS releases).
>
> * Unofficial support, by persons willing to volunteer their time, will
>   be permitted through a secondary code repository existing solely to
>   provide this support.
>
> * As the official end-of-life of each Django version approaches, the
>   Django core team will solicit proposals and volunteers to provide
>   unofficial support for that version past its official end-of-life,
>   and select maintainer(s) from amongst those volunteers. This support
>   will be known as "community maintenance".
>
>
> Rationale
> -
>
> For the past five years, Django has been in the process of deprecating
> support for older 2.x release of Python, as part of a plan to move
> Django toward, first, compatibility with both Python 2 and Python 3
> (completed as of Django 1.6), and ultimately with only Python 3 (in a
> future, to-be-determined, release).
>
> The timeline for this was as follows:
>
> * May 2010: Django 1.2 instituted a minimum Python version of 2.4.
>
> * March 2011: Django 1.3 was the final release to support Python 2.4.
>
> * March 2012: Django 1.4 (LTS) raised the minimum Python version to
>   2.5, and was the final release to support Python 2.5.
>
> * February 2013: Django 1.5 raised the minimum Python version to 2.6.
>
> * November 2013: Django 1.6 was the final release to support Python
>   2.6.
>
> * September 2014: Django 1.7 raised the minimum Python version to 2.7.
>
> * Late Q1/early Q2 2015: Django 1.4 and Django 1.6 will reach
>   end-of-life (the former on a scheduled date, the latter upon the
>   release of Django 1.8).
>
> While this process was necessary to achieve at least a minimum of
> Python 2.6 (the lowest version enabling compatibility with Python 2
> and Python 3 in a single codebase) and ultimately a minimum of Python
> 2.7 (the only Python 2.x release still receiving upstream security
> support), and while moving Django in the direction of Python 3 is an
> absolute necessity for the future of the framework, this has had an
> effect on some users of Django who are effectively locked in to now-
> or soon-to-be-unsupported versions of Python by their choice of
> operating system and associated support contract.
>
> In particular, the impending end-of-life of Django 1.6, the final
> release which supported Python 2.6, is poised to cut off support for
> users of products like Red Hat Enterprise Linux, who may be locked to
> Python 2.6 and thus unable to use a supported version of Django past
> 1.6 end-of-life (these users continue to receive security support for
> Python itself from the operating-system vendor, who provides such
> support on their behalf even after official upstream support has
> ended; no such support appears to be provided, at this time, for
> Django).
>
> Although these users are not a majority of Django's users, they are
> still a significant group, and simply ending their ability to use
> Django is likely to be an unacceptable option. But the Django core
> team cannot and will not extend the official support lifetimes of
> older Django releases; the additional maintenance burden is beyond
> that which can be borne, and would impede the future development of
> Django.
>
> This is not the first time in Django's history that a significant
> minority of users have been affected by 

Pre-DEP: community support of unmaintained versions of Django

[James Bennett]

There's been some recent discussion in a django-users thread[1] about
the impending end-of-life of Django 1.6, which in turn will mean
end-of-life for Django supported on Python 2.6. In addition, the
end-of-life of the current LTS release, Django 1.4, will mean
end-of-life for Django supported on Python 2.5. The following is a
draft of a proposal based on ideas raised in that thread; it should be
considered pre-DEP status, to be elevated to a DEP submission if there
is sufficient support.


Abstract


The support process for older versions of Django is changed, as
follows:

* Official support for older versions of Django from the Django core
  team will continue to end at the scheduled times (i.e., upon release
  of a new minor version for non-LTS releases, at end of advertised
  support lifetime for LTS releases).

* Unofficial support, by persons willing to volunteer their time, will
  be permitted through a secondary code repository existing solely to
  provide this support.

* As the official end-of-life of each Django version approaches, the
  Django core team will solicit proposals and volunteers to provide
  unofficial support for that version past its official end-of-life,
  and select maintainer(s) from amongst those volunteers. This support
  will be known as "community maintenance".


Rationale
-

For the past five years, Django has been in the process of deprecating
support for older 2.x release of Python, as part of a plan to move
Django toward, first, compatibility with both Python 2 and Python 3
(completed as of Django 1.6), and ultimately with only Python 3 (in a
future, to-be-determined, release).

The timeline for this was as follows:

* May 2010: Django 1.2 instituted a minimum Python version of 2.4.

* March 2011: Django 1.3 was the final release to support Python 2.4.

* March 2012: Django 1.4 (LTS) raised the minimum Python version to
  2.5, and was the final release to support Python 2.5.

* February 2013: Django 1.5 raised the minimum Python version to 2.6.

* November 2013: Django 1.6 was the final release to support Python
  2.6.

* September 2014: Django 1.7 raised the minimum Python version to 2.7.

* Late Q1/early Q2 2015: Django 1.4 and Django 1.6 will reach
  end-of-life (the former on a scheduled date, the latter upon the
  release of Django 1.8).

While this process was necessary to achieve at least a minimum of
Python 2.6 (the lowest version enabling compatibility with Python 2
and Python 3 in a single codebase) and ultimately a minimum of Python
2.7 (the only Python 2.x release still receiving upstream security
support), and while moving Django in the direction of Python 3 is an
absolute necessity for the future of the framework, this has had an
effect on some users of Django who are effectively locked in to now-
or soon-to-be-unsupported versions of Python by their choice of
operating system and associated support contract.

In particular, the impending end-of-life of Django 1.6, the final
release which supported Python 2.6, is poised to cut off support for
users of products like Red Hat Enterprise Linux, who may be locked to
Python 2.6 and thus unable to use a supported version of Django past
1.6 end-of-life (these users continue to receive security support for
Python itself from the operating-system vendor, who provides such
support on their behalf even after official upstream support has
ended; no such support appears to be provided, at this time, for
Django).

Although these users are not a majority of Django's users, they are
still a significant group, and simply ending their ability to use
Django is likely to be an unacceptable option. But the Django core
team cannot and will not extend the official support lifetimes of
older Django releases; the additional maintenance burden is beyond
that which can be borne, and would impede the future development of
Django.

This is not the first time in Django's history that a significant
minority of users have been affected by backwards-incompatible
releases. Prior to Django 1.0, the large incompatibility of the
"magic-removal" branch, merged shortly before the release of Django
0.95, left some users effectively stranded with large already-existing
codebases that could not be quickly migrated.

During that time period, the Django core team allowed, on an
unofficial volunteer basis, continuing bugfix and security support to
be provided by interested parties for an extended period of time past
the official end-of-life of Django 0.91. This support was conducted
solely through commits to Django's (at the time Subversion)
repository, and never through issuing additional releases in an
end-of-life'd release series.

This experiment in unofficial support was successful overall; many
high-visibility installations of Django were able to migrate to
post-"magic-removal" versions of Django at the best pace they could
manage, while still being assured of necessary support for security
and crashing/data-loss issues on their