Re: 1.9 release planning

[Tim Graham]

Thanks to everyone for feedback! The technical board has signed off on 
these changes. Here are the results:

https://www.djangoproject.com/weblog/2015/jun/25/roadmap/ - Django’s Roadmap

https://github.com/django/django/pull/4897 - Updated release process for 
new release schedule.

https://github.com/django/djangoproject.com/pull/493 - Added roadmap of 
future versions to download page.

https://github.com/django/deps/pull/16 - DEP 4: Release Schedule

https://github.com/django/django/pull/4916 - Renamed deprecation warnings 
on master
https://github.com/django/django/pull/4908 - [1.8.x] Renamed 
RemovedInDjango20Warning to RemovedInDjango110Warning.

On Wednesday, June 24, 2015 at 2:10:52 PM UTC-4, Chris Foresman wrote:
>
> For an additional non-core dev data point, I'm also +1 on Loic's 1.10, 
> 1.11, 2.0... plan. Makes it much easier to plan and communicate framework 
> upgrades to clients.
>
>
>
> On Tuesday, June 23, 2015 at 9:14:25 PM UTC-5, Josh Smeaton wrote:
>>
>> I was worried about 1.10 because I wrongly assumed that the entire 
>> version string was ordered. SemVer (and 
>> https://www.python.org/dev/peps/pep-0386/) specifically call out that 
>> each component of a version identifier MUST be ordered numerically. My 
>> objections based on that incorrect assumption I withdraw.
>>
>> I'm +1 on going to 1.10, 1.11, then to 2.0. I think it makes sense, and 
>> nicely aligns with the emerging new policy. I don't think we should be held 
>> to naming the version after 1.9 as 2.0, considering we're changing the 
>> policy of backwards compatibility, the semantics of the version numbers, 
>> and the timelines of LTS. Do it all at once, and I think that sends a much 
>> stronger message.
>>
>> Cheers
>>
>> On Wednesday, 24 June 2015 02:31:11 UTC+10, Carl Meyer wrote:
>>>
>>> I am +1 on the 1.10 - 1.11 - 2.0 plan; I think the discrepancy between 
>>> 2.x and the future version numbering scheme will in practice be _much_ 
>>> more confusing (and already has been). 
>>>
>>> I have never found any objection to 1.10-style version numbers 
>>> convincing. Dotted version numbers are clearly a representation of a 
>>> tuple of integers, not an odd decimal notation, as evidenced by the fact 
>>> that every commonly-used dotted version numbering scheme invests each 
>>> location in the tuple with some kind of semantics. In any case, 
>>> precedent for such version numbers in Django was set several years ago 
>>> when we shipped 1.4.10; by now we're up to 1.4.20! (Not to mention 
>>> 1.5.12 and 1.6.11). 
>>>
>>> FWIW, I did a GitHub code search and in the first ten pages of results I 
>>> found zero uses of RemovedInDjango20Warning that weren't instances of 
>>> someone committing their virtualenv (with a copy of Django) to git. So I 
>>> am not concerned about changing those warnings (especially since we can 
>>> provide backwards compatibility). 
>>>
>>> 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/53a66fe3-3ba3-4766-b715-604321252d2c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Chris Foresman]

For an additional non-core dev data point, I'm also +1 on Loic's 1.10, 
1.11, 2.0... plan. Makes it much easier to plan and communicate framework 
upgrades to clients.



On Tuesday, June 23, 2015 at 9:14:25 PM UTC-5, Josh Smeaton wrote:
>
> I was worried about 1.10 because I wrongly assumed that the entire version 
> string was ordered. SemVer (and https://www.python.org/dev/peps/pep-0386/) 
> specifically call out that each component of a version identifier MUST be 
> ordered numerically. My objections based on that incorrect assumption I 
> withdraw.
>
> I'm +1 on going to 1.10, 1.11, then to 2.0. I think it makes sense, and 
> nicely aligns with the emerging new policy. I don't think we should be held 
> to naming the version after 1.9 as 2.0, considering we're changing the 
> policy of backwards compatibility, the semantics of the version numbers, 
> and the timelines of LTS. Do it all at once, and I think that sends a much 
> stronger message.
>
> Cheers
>
> On Wednesday, 24 June 2015 02:31:11 UTC+10, Carl Meyer wrote:
>>
>> I am +1 on the 1.10 - 1.11 - 2.0 plan; I think the discrepancy between 
>> 2.x and the future version numbering scheme will in practice be _much_ 
>> more confusing (and already has been). 
>>
>> I have never found any objection to 1.10-style version numbers 
>> convincing. Dotted version numbers are clearly a representation of a 
>> tuple of integers, not an odd decimal notation, as evidenced by the fact 
>> that every commonly-used dotted version numbering scheme invests each 
>> location in the tuple with some kind of semantics. In any case, 
>> precedent for such version numbers in Django was set several years ago 
>> when we shipped 1.4.10; by now we're up to 1.4.20! (Not to mention 
>> 1.5.12 and 1.6.11). 
>>
>> FWIW, I did a GitHub code search and in the first ten pages of results I 
>> found zero uses of RemovedInDjango20Warning that weren't instances of 
>> someone committing their virtualenv (with a copy of Django) to git. So I 
>> am not concerned about changing those warnings (especially since we can 
>> provide backwards compatibility). 
>>
>> 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/d83ee0d0-89ba-437a-819b-6083dd7f5023%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Josh Smeaton]

I was worried about 1.10 because I wrongly assumed that the entire version 
string was ordered. SemVer (and https://www.python.org/dev/peps/pep-0386/) 
specifically call out that each component of a version identifier MUST be 
ordered numerically. My objections based on that incorrect assumption I 
withdraw.

I'm +1 on going to 1.10, 1.11, then to 2.0. I think it makes sense, and 
nicely aligns with the emerging new policy. I don't think we should be held 
to naming the version after 1.9 as 2.0, considering we're changing the 
policy of backwards compatibility, the semantics of the version numbers, 
and the timelines of LTS. Do it all at once, and I think that sends a much 
stronger message.

Cheers

On Wednesday, 24 June 2015 02:31:11 UTC+10, Carl Meyer wrote:
>
> I am +1 on the 1.10 - 1.11 - 2.0 plan; I think the discrepancy between 
> 2.x and the future version numbering scheme will in practice be _much_ 
> more confusing (and already has been). 
>
> I have never found any objection to 1.10-style version numbers 
> convincing. Dotted version numbers are clearly a representation of a 
> tuple of integers, not an odd decimal notation, as evidenced by the fact 
> that every commonly-used dotted version numbering scheme invests each 
> location in the tuple with some kind of semantics. In any case, 
> precedent for such version numbers in Django was set several years ago 
> when we shipped 1.4.10; by now we're up to 1.4.20! (Not to mention 
> 1.5.12 and 1.6.11). 
>
> FWIW, I did a GitHub code search and in the first ten pages of results I 
> found zero uses of RemovedInDjango20Warning that weren't instances of 
> someone committing their virtualenv (with a copy of Django) to git. So I 
> am not concerned about changing those warnings (especially since we can 
> provide backwards compatibility). 
>
> 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/d433ab7a-66e0-45fb-8a2c-d8775d574466%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Carl Meyer]

I am +1 on the 1.10 - 1.11 - 2.0 plan; I think the discrepancy between
2.x and the future version numbering scheme will in practice be _much_
more confusing (and already has been).

I have never found any objection to 1.10-style version numbers
convincing. Dotted version numbers are clearly a representation of a
tuple of integers, not an odd decimal notation, as evidenced by the fact
that every commonly-used dotted version numbering scheme invests each
location in the tuple with some kind of semantics. In any case,
precedent for such version numbers in Django was set several years ago
when we shipped 1.4.10; by now we're up to 1.4.20! (Not to mention
1.5.12 and 1.6.11).

FWIW, I did a GitHub code search and in the first ten pages of results I
found zero uses of RemovedInDjango20Warning that weren't instances of
someone committing their virtualenv (with a copy of Django) to git. So I
am not concerned about changing those warnings (especially since we can
provide backwards compatibility).

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/558989BE.3090906%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: 1.9 release planning

[Aymeric Augustin]

OK, count me as -0 ;-)

-- 
Aymeric.

2015-06-23 13:23 GMT+02:00 Loïc Bistuer :

>
> > On Jun 23, 2015, at 17:24, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
> >
> > I'm against making changes to the version numbers we've already planned
> for and also against 1.10, 1.11 etc. version numbers.
> >
> > Such numbers can easily break version checks that don't expect this
> case. There's lots of code in the wild with version checks, some of which
> will probably behave incorrectly.
>
> I'm not very sympathetic to code that relies on undefined behaviours,
> especially when people have 2 releases to prepare for the change. We'd
> properly document it in the 1.10 release notes.
>
> > Besides, honestly, 1.10 is just ugly :-)
>
> I don't really see anything wrong with 1.10+ versions but maybe that's
> because this scheme is commonplace in libraries that I've used. The 2.0 and
> 2.1 exceptions to the new policy are even uglier to me and already
> introduced a fair amount of confusion to people reviewing the proposals.
>
> Also I really like that Django 2.0 would coincide with dropping support
> for Python 2. That's most certainly the biggest backwards incompatibility
> we'll ever have :)
>
> --
> Loïc
>
> --
> 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/76292589-2340-46DB-BB4D-F38414332B2D%40gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
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-7mWBw7a_0xGO88d8V3cbdYjjKV%2Bu_k7ztOVyeaWpQiZPWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Anders Steinlein]

2015-06-23 13:23 GMT+02:00 Loïc Bistuer :

>
> > On Jun 23, 2015, at 17:24, Aymeric Augustin <
> aymeric.augus...@polytechnique.org> wrote:
> >
> > Besides, honestly, 1.10 is just ugly :-)
>
> I don't really see anything wrong with 1.10+ versions but maybe that's
> because this scheme is commonplace in libraries that I've used. The 2.0 and
> 2.1 exceptions to the new policy are even uglier to me and already
> introduced a fair amount of confusion to people reviewing the proposals.
>
> Also I really like that Django 2.0 would coincide with dropping support
> for Python 2. That's most certainly the biggest backwards incompatibility
> we'll ever have :)
>

Just wanted to voice my opinion from the sidelines as a "regular developer"
(Django user) here. I'm very much +1 to Loïc's suggestion. The changes to
originally planned version numbering is a very minor inconvenience compared
to the confusing 2.0 and 2.1 exceptions. Aligning as closely to semver as
possibe is a much less confusing, IMHO, and 1.10+ version numbering
(whether one think it's "ugly" or not) is commonplace with semver
versioning. Frankly, bumping to 2.0 for no special reason other than it
being "after 1.9" is more confusing than going to 1.10 and having 2.0 being
a backwards-breaking release.

Cheers,
Anders

-- 
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/CAC35HNn4w3pCOpKHjoxaXmTfisKo%3D1X8c2p43MNYVeYYMryGuQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Loïc Bistuer]

> On Jun 23, 2015, at 17:24, Aymeric Augustin 
>  wrote:
> 
> I'm against making changes to the version numbers we've already planned for 
> and also against 1.10, 1.11 etc. version numbers.
> 
> Such numbers can easily break version checks that don't expect this case. 
> There's lots of code in the wild with version checks, some of which will 
> probably behave incorrectly.

I'm not very sympathetic to code that relies on undefined behaviours, 
especially when people have 2 releases to prepare for the change. We'd properly 
document it in the 1.10 release notes.

> Besides, honestly, 1.10 is just ugly :-)

I don't really see anything wrong with 1.10+ versions but maybe that's because 
this scheme is commonplace in libraries that I've used. The 2.0 and 2.1 
exceptions to the new policy are even uglier to me and already introduced a 
fair amount of confusion to people reviewing the proposals.

Also I really like that Django 2.0 would coincide with dropping support for 
Python 2. That's most certainly the biggest backwards incompatibility we'll 
ever have :)

-- 
Loïc

-- 
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/76292589-2340-46DB-BB4D-F38414332B2D%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Anssi Kääriäinen]

+1 to not changing already planned version numbers.

 - Anssi

On Tue, Jun 23, 2015 at 1:24 PM, Aymeric Augustin
 wrote:
> I'm against making changes to the version numbers we've already planned for
> and also against 1.10, 1.11 etc. version numbers.
>
> Such numbers can easily break version checks that don't expect this case.
> There's lots of code in the wild with version checks, some of which will
> probably behave incorrectly.
>
> Besides, honestly, 1.10 is just ugly :-)
>
> --
> Aymeric.
>
>
>
> 2015-06-23 9:43 GMT+02:00 Marc Tamlyn :
>>
>> +1 to 1.11
>>
>> It was an arbitrary decision not to use 2.0 in the first place because we
>> were not going to do special version numbers. Now Y.0 is a special version
>> (dropping backwards compat after the LTS) it makes more sense.
>>
>> Marc
>>
>> On 22 Jun 2015 19:28, "Tim Graham"  wrote:
>>>
>>> Done that in https://github.com/django/django/pull/4908
>>>
>>> On Monday, June 22, 2015 at 1:35:19 PM UTC-4, Loïc Bistuer wrote:

 We can just leave RemovedInDjango20Warning as an alias (not a subclass)
 to PendingDeprecationWarning in 1.8. As long as we don't refer to it in the
 rest of the codebase it isn't ambiguous.

 --
 Loïc

 > On Jun 23, 2015, at 00:21, Collin Anderson  wrote:
 >
 > People import the warning in order to silence them, right?
 >
 > On Monday, June 22, 2015 at 1:19:51 PM UTC-4, Markus Holtermann wrote:
 > +1 -- Going with 1.8, 1.9, 1.10, 1.11 (LTS), 2.0 sounds like a solid
 > plan. I don't think any of the (Pending)DeprecationWarnings are much
 > of
 > a public API. I've never seen them in the wild.
 >
 > /Markus
 >
 > On Mon, Jun 22, 2015 at 11:20:52AM -0400, Michael Manfre wrote:
 > >+1. I really don't like the idea of 2.x being odd.
 > >
 > >On Mon, Jun 22, 2015 at 10:33 AM, Loïc Bistuer 
 > >wrote:
 > >
 > >> Just when we thought we had a winner... I'd like to make a final
 > >> proposal.
 > >>
 > >> Instead of delaying adoption of SemVer to 3.0 we could do so in 2.0
 > >> by
 > >> introducing the 1.10 and 1.11LTS releases.
 > >>
 > >> The upside is that the new policy applies right away and we avoid
 > >> the
 > >> oddball 2.0 and 2.1 releases.
 > >>
 > >> It's much less invasive than the previous idea of renaming 1.9 to
 > >> 2.0, but
 > >> it still requires renaming PendingDeprecationWarnings in 1.8, and
 > >> both
 > >> warnings in 1.9.
 > >>
 > >> What do you think?
 > >>
 > >> --
 > >> Loïc
 > >>
 > >> > On Jun 17, 2015, at 08:47, Josh Smeaton 
 > >> > wrote:
 > >> >
 > >> > I'm also +1 on the proposal as it stands, and neutral on when the
 > >> > semver
 > >> versioning should begin.
 > >> >
 > >> > On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote:
 > >> > I'm +1 on the Google doc proposal and like Markus, I support
 > >> > relabeling
 > >> 1.9 to 2.0 to line the versions up with the new paradigm without
 > >> the X.1
 > >> LTS oddball.
 > >> >
 > >> > Regards,
 > >> > Michael Manfre
 > >> >
 > >> > On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson
 > >> > 
 > >> wrote:
 > >> > I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0,
 > >> > 3.1,
 > >> 3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and
 > >> we
 > >> sacrifice a little bit of strict semver, but it give some nice
 > >> meaning to
 > >> the version numbers.
 > >> >
 > >> >
 > >> > On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote:
 > >> > Thanks Loïc,
 > >> >
 > >> > On 06/16/2015 01:15 AM, Loïc Bistuer wrote:
 > >> > > I've attempted to summarize the history of this thread. Note
 > >> > > that I
 > >> > > marked as +1 any generally positive feedback towards a given
 > >> > > proposal, please correct if you feel misrepresented.
 > >> > >
 > >> > [snip]
 > >> > >
 > >> > > # Third iteration:
 > >> > >
 > >> > > 5/ Switching to Semantic Versioning
 > >> > >
 > >> > > Donald mentioned SemVer on IRC a few days ago. Since then
 > >> > > various
 > >> > > proposal were made to reconcile it with our release policy. So
 > >> > > far
 > >> > > Collin, Carl, Loïc, Tim, and Josh have expressed positive
 > >> > > feedback to
 > >> > > various proposals in that direction but I don't think we have
 > >> > > yet
 > >> > > reached consensus on a specific one. Tim updated the Google doc
 > >> > > to
 > >> > > reflect my latest proposal, so including me that's 2 formal +1
 > >> > > for
 > >> > > it, but I'd say we should wait for at least a couple more votes

Re: 1.9 release planning

[Aymeric Augustin]

I'm against making changes to the version numbers we've already planned for
and also against 1.10, 1.11 etc. version numbers.

Such numbers can easily break version checks that don't expect this case.
There's lots of code in the wild with version checks, some of which will
probably behave incorrectly.

Besides, honestly, 1.10 is just ugly :-)

-- 
Aymeric.



2015-06-23 9:43 GMT+02:00 Marc Tamlyn :

> +1 to 1.11
>
> It was an arbitrary decision not to use 2.0 in the first place because we
> were not going to do special version numbers. Now Y.0 is a special version
> (dropping backwards compat after the LTS) it makes more sense.
>
> Marc
> On 22 Jun 2015 19:28, "Tim Graham"  wrote:
>
>> Done that in https://github.com/django/django/pull/4908
>>
>> On Monday, June 22, 2015 at 1:35:19 PM UTC-4, Loïc Bistuer wrote:
>>>
>>> We can just leave RemovedInDjango20Warning as an alias (not a subclass)
>>> to PendingDeprecationWarning in 1.8. As long as we don't refer to it in the
>>> rest of the codebase it isn't ambiguous.
>>>
>>> --
>>> Loïc
>>>
>>> > On Jun 23, 2015, at 00:21, Collin Anderson 
>>> wrote:
>>> >
>>> > People import the warning in order to silence them, right?
>>> >
>>> > On Monday, June 22, 2015 at 1:19:51 PM UTC-4, Markus Holtermann wrote:
>>> > +1 -- Going with 1.8, 1.9, 1.10, 1.11 (LTS), 2.0 sounds like a solid
>>> > plan. I don't think any of the (Pending)DeprecationWarnings are much
>>> of
>>> > a public API. I've never seen them in the wild.
>>> >
>>> > /Markus
>>> >
>>> > On Mon, Jun 22, 2015 at 11:20:52AM -0400, Michael Manfre wrote:
>>> > >+1. I really don't like the idea of 2.x being odd.
>>> > >
>>> > >On Mon, Jun 22, 2015 at 10:33 AM, Loïc Bistuer 
>>> > >wrote:
>>> > >
>>> > >> Just when we thought we had a winner... I'd like to make a final
>>> proposal.
>>> > >>
>>> > >> Instead of delaying adoption of SemVer to 3.0 we could do so in 2.0
>>> by
>>> > >> introducing the 1.10 and 1.11LTS releases.
>>> > >>
>>> > >> The upside is that the new policy applies right away and we avoid
>>> the
>>> > >> oddball 2.0 and 2.1 releases.
>>> > >>
>>> > >> It's much less invasive than the previous idea of renaming 1.9 to
>>> 2.0, but
>>> > >> it still requires renaming PendingDeprecationWarnings in 1.8, and
>>> both
>>> > >> warnings in 1.9.
>>> > >>
>>> > >> What do you think?
>>> > >>
>>> > >> --
>>> > >> Loïc
>>> > >>
>>> > >> > On Jun 17, 2015, at 08:47, Josh Smeaton 
>>> wrote:
>>> > >> >
>>> > >> > I'm also +1 on the proposal as it stands, and neutral on when the
>>> semver
>>> > >> versioning should begin.
>>> > >> >
>>> > >> > On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote:
>>> > >> > I'm +1 on the Google doc proposal and like Markus, I support
>>> relabeling
>>> > >> 1.9 to 2.0 to line the versions up with the new paradigm without
>>> the X.1
>>> > >> LTS oddball.
>>> > >> >
>>> > >> > Regards,
>>> > >> > Michael Manfre
>>> > >> >
>>> > >> > On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson <
>>> cmawe...@gmail.com>
>>> > >> wrote:
>>> > >> > I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0,
>>> 3.1,
>>> > >> 3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and
>>> we
>>> > >> sacrifice a little bit of strict semver, but it give some nice
>>> meaning to
>>> > >> the version numbers.
>>> > >> >
>>> > >> >
>>> > >> > On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote:
>>> > >> > Thanks Loïc,
>>> > >> >
>>> > >> > On 06/16/2015 01:15 AM, Loïc Bistuer wrote:
>>> > >> > > I've attempted to summarize the history of this thread. Note
>>> that I
>>> > >> > > marked as +1 any generally positive feedback towards a given
>>> > >> > > proposal, please correct if you feel misrepresented.
>>> > >> > >
>>> > >> > [snip]
>>> > >> > >
>>> > >> > > # Third iteration:
>>> > >> > >
>>> > >> > > 5/ Switching to Semantic Versioning
>>> > >> > >
>>> > >> > > Donald mentioned SemVer on IRC a few days ago. Since then
>>> various
>>> > >> > > proposal were made to reconcile it with our release policy. So
>>> far
>>> > >> > > Collin, Carl, Loïc, Tim, and Josh have expressed positive
>>> feedback to
>>> > >> > > various proposals in that direction but I don't think we have
>>> yet
>>> > >> > > reached consensus on a specific one. Tim updated the Google doc
>>> to
>>> > >> > > reflect my latest proposal, so including me that's 2 formal +1
>>> for
>>> > >> > > it, but I'd say we should wait for at least a couple more votes
>>> > >> > > before taking it to the technical board.
>>> > >> > >
>>> > >> > > Refs: - http://semver.org/ - Carl's analysis
>>> > >> > >
>>> > >>
>>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
>>> > >> > >
>>> > >> > >
>>> > >> > - Ryan's proposals
>>> > >> >
>>> > >>
>>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
>>> > >> > > - Loïc's proposal
>>> > >> > >
>>> > >>
>>> 

Re: 1.9 release planning

[Marc Tamlyn]

+1 to 1.11

It was an arbitrary decision not to use 2.0 in the first place because we
were not going to do special version numbers. Now Y.0 is a special version
(dropping backwards compat after the LTS) it makes more sense.

Marc
On 22 Jun 2015 19:28, "Tim Graham"  wrote:

> Done that in https://github.com/django/django/pull/4908
>
> On Monday, June 22, 2015 at 1:35:19 PM UTC-4, Loïc Bistuer wrote:
>>
>> We can just leave RemovedInDjango20Warning as an alias (not a subclass)
>> to PendingDeprecationWarning in 1.8. As long as we don't refer to it in the
>> rest of the codebase it isn't ambiguous.
>>
>> --
>> Loïc
>>
>> > On Jun 23, 2015, at 00:21, Collin Anderson  wrote:
>> >
>> > People import the warning in order to silence them, right?
>> >
>> > On Monday, June 22, 2015 at 1:19:51 PM UTC-4, Markus Holtermann wrote:
>> > +1 -- Going with 1.8, 1.9, 1.10, 1.11 (LTS), 2.0 sounds like a solid
>> > plan. I don't think any of the (Pending)DeprecationWarnings are much of
>> > a public API. I've never seen them in the wild.
>> >
>> > /Markus
>> >
>> > On Mon, Jun 22, 2015 at 11:20:52AM -0400, Michael Manfre wrote:
>> > >+1. I really don't like the idea of 2.x being odd.
>> > >
>> > >On Mon, Jun 22, 2015 at 10:33 AM, Loïc Bistuer 
>> > >wrote:
>> > >
>> > >> Just when we thought we had a winner... I'd like to make a final
>> proposal.
>> > >>
>> > >> Instead of delaying adoption of SemVer to 3.0 we could do so in 2.0
>> by
>> > >> introducing the 1.10 and 1.11LTS releases.
>> > >>
>> > >> The upside is that the new policy applies right away and we avoid
>> the
>> > >> oddball 2.0 and 2.1 releases.
>> > >>
>> > >> It's much less invasive than the previous idea of renaming 1.9 to
>> 2.0, but
>> > >> it still requires renaming PendingDeprecationWarnings in 1.8, and
>> both
>> > >> warnings in 1.9.
>> > >>
>> > >> What do you think?
>> > >>
>> > >> --
>> > >> Loïc
>> > >>
>> > >> > On Jun 17, 2015, at 08:47, Josh Smeaton 
>> wrote:
>> > >> >
>> > >> > I'm also +1 on the proposal as it stands, and neutral on when the
>> semver
>> > >> versioning should begin.
>> > >> >
>> > >> > On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote:
>> > >> > I'm +1 on the Google doc proposal and like Markus, I support
>> relabeling
>> > >> 1.9 to 2.0 to line the versions up with the new paradigm without the
>> X.1
>> > >> LTS oddball.
>> > >> >
>> > >> > Regards,
>> > >> > Michael Manfre
>> > >> >
>> > >> > On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson <
>> cmawe...@gmail.com>
>> > >> wrote:
>> > >> > I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0,
>> 3.1,
>> > >> 3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and
>> we
>> > >> sacrifice a little bit of strict semver, but it give some nice
>> meaning to
>> > >> the version numbers.
>> > >> >
>> > >> >
>> > >> > On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote:
>> > >> > Thanks Loïc,
>> > >> >
>> > >> > On 06/16/2015 01:15 AM, Loïc Bistuer wrote:
>> > >> > > I've attempted to summarize the history of this thread. Note
>> that I
>> > >> > > marked as +1 any generally positive feedback towards a given
>> > >> > > proposal, please correct if you feel misrepresented.
>> > >> > >
>> > >> > [snip]
>> > >> > >
>> > >> > > # Third iteration:
>> > >> > >
>> > >> > > 5/ Switching to Semantic Versioning
>> > >> > >
>> > >> > > Donald mentioned SemVer on IRC a few days ago. Since then
>> various
>> > >> > > proposal were made to reconcile it with our release policy. So
>> far
>> > >> > > Collin, Carl, Loïc, Tim, and Josh have expressed positive
>> feedback to
>> > >> > > various proposals in that direction but I don't think we have
>> yet
>> > >> > > reached consensus on a specific one. Tim updated the Google doc
>> to
>> > >> > > reflect my latest proposal, so including me that's 2 formal +1
>> for
>> > >> > > it, but I'd say we should wait for at least a couple more votes
>> > >> > > before taking it to the technical board.
>> > >> > >
>> > >> > > Refs: - http://semver.org/ - Carl's analysis
>> > >> > >
>> > >>
>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
>> > >> > >
>> > >> > >
>> > >> > - Ryan's proposals
>> > >> >
>> > >>
>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
>> > >> > > - Loïc's proposal
>> > >> > >
>> > >>
>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ
>> > >> >
>> > >> > FWIW, I am also +1 on your proposal, as currently documented in
>> the
>> > >> > Google doc.
>> > >> >
>> > >> > I was trying to come up with a proposal where LTS == major release
>> for
>> > >> > the sake of argument, since it seemed like that was intuitive to
>> at
>> > >> > least some people, but it's not worth the required lengthening of
>> > >> > deprecation paths. Your proposal is much better. (And it does make
>> some
>> > >> > intuitive sense for the _last_ minor 

Re: 1.9 release planning

[Tim Graham]

Done that in https://github.com/django/django/pull/4908

On Monday, June 22, 2015 at 1:35:19 PM UTC-4, Loïc Bistuer wrote:
>
> We can just leave RemovedInDjango20Warning as an alias (not a subclass) to 
> PendingDeprecationWarning in 1.8. As long as we don't refer to it in the 
> rest of the codebase it isn't ambiguous. 
>
> -- 
> Loïc 
>
> > On Jun 23, 2015, at 00:21, Collin Anderson  > wrote: 
> > 
> > People import the warning in order to silence them, right? 
> > 
> > On Monday, June 22, 2015 at 1:19:51 PM UTC-4, Markus Holtermann wrote: 
> > +1 -- Going with 1.8, 1.9, 1.10, 1.11 (LTS), 2.0 sounds like a solid 
> > plan. I don't think any of the (Pending)DeprecationWarnings are much of 
> > a public API. I've never seen them in the wild. 
> > 
> > /Markus 
> > 
> > On Mon, Jun 22, 2015 at 11:20:52AM -0400, Michael Manfre wrote: 
> > >+1. I really don't like the idea of 2.x being odd. 
> > > 
> > >On Mon, Jun 22, 2015 at 10:33 AM, Loïc Bistuer  
> > >wrote: 
> > > 
> > >> Just when we thought we had a winner... I'd like to make a final 
> proposal. 
> > >> 
> > >> Instead of delaying adoption of SemVer to 3.0 we could do so in 2.0 
> by 
> > >> introducing the 1.10 and 1.11LTS releases. 
> > >> 
> > >> The upside is that the new policy applies right away and we avoid the 
> > >> oddball 2.0 and 2.1 releases. 
> > >> 
> > >> It's much less invasive than the previous idea of renaming 1.9 to 
> 2.0, but 
> > >> it still requires renaming PendingDeprecationWarnings in 1.8, and 
> both 
> > >> warnings in 1.9. 
> > >> 
> > >> What do you think? 
> > >> 
> > >> -- 
> > >> Loïc 
> > >> 
> > >> > On Jun 17, 2015, at 08:47, Josh Smeaton  
> wrote: 
> > >> > 
> > >> > I'm also +1 on the proposal as it stands, and neutral on when the 
> semver 
> > >> versioning should begin. 
> > >> > 
> > >> > On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote: 
> > >> > I'm +1 on the Google doc proposal and like Markus, I support 
> relabeling 
> > >> 1.9 to 2.0 to line the versions up with the new paradigm without the 
> X.1 
> > >> LTS oddball. 
> > >> > 
> > >> > Regards, 
> > >> > Michael Manfre 
> > >> > 
> > >> > On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson <
> cmawe...@gmail.com> 
> > >> wrote: 
> > >> > I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 
> 3.1, 
> > >> 3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and 
> we 
> > >> sacrifice a little bit of strict semver, but it give some nice 
> meaning to 
> > >> the version numbers. 
> > >> > 
> > >> > 
> > >> > On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote: 
> > >> > Thanks Loïc, 
> > >> > 
> > >> > On 06/16/2015 01:15 AM, Loïc Bistuer wrote: 
> > >> > > I've attempted to summarize the history of this thread. Note that 
> I 
> > >> > > marked as +1 any generally positive feedback towards a given 
> > >> > > proposal, please correct if you feel misrepresented. 
> > >> > > 
> > >> > [snip] 
> > >> > > 
> > >> > > # Third iteration: 
> > >> > > 
> > >> > > 5/ Switching to Semantic Versioning 
> > >> > > 
> > >> > > Donald mentioned SemVer on IRC a few days ago. Since then various 
> > >> > > proposal were made to reconcile it with our release policy. So 
> far 
> > >> > > Collin, Carl, Loïc, Tim, and Josh have expressed positive 
> feedback to 
> > >> > > various proposals in that direction but I don't think we have yet 
> > >> > > reached consensus on a specific one. Tim updated the Google doc 
> to 
> > >> > > reflect my latest proposal, so including me that's 2 formal +1 
> for 
> > >> > > it, but I'd say we should wait for at least a couple more votes 
> > >> > > before taking it to the technical board. 
> > >> > > 
> > >> > > Refs: - http://semver.org/ - Carl's analysis 
> > >> > > 
> > >> 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J 
> > >> > > 
> > >> > > 
> > >> > - Ryan's proposals 
> > >> > 
> > >> 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ 
> > >> > > - Loïc's proposal 
> > >> > > 
> > >> 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ 
> > >> > 
> > >> > FWIW, I am also +1 on your proposal, as currently documented in the 
> > >> > Google doc. 
> > >> > 
> > >> > I was trying to come up with a proposal where LTS == major release 
> for 
> > >> > the sake of argument, since it seemed like that was intuitive to at 
> > >> > least some people, but it's not worth the required lengthening of 
> > >> > deprecation paths. Your proposal is much better. (And it does make 
> some 
> > >> > intuitive sense for the _last_ minor release in a major series to 
> be LTS 
> > >> > rather than the first). 
> > >> > 
> > >> > Carl 
> > >> > 
> > >> > 
> > >> > -- 
> > >> > You received this message because you are subscribed to the Google 
> > >> Groups "Django developers (Contributions to Django itself)" group. 
> > >> > To unsubscribe from this 

Re: 1.9 release planning

[Loïc Bistuer]

We can just leave RemovedInDjango20Warning as an alias (not a subclass) to 
PendingDeprecationWarning in 1.8. As long as we don't refer to it in the rest 
of the codebase it isn't ambiguous.

-- 
Loïc

> On Jun 23, 2015, at 00:21, Collin Anderson  wrote:
> 
> People import the warning in order to silence them, right?
> 
> On Monday, June 22, 2015 at 1:19:51 PM UTC-4, Markus Holtermann wrote:
> +1 -- Going with 1.8, 1.9, 1.10, 1.11 (LTS), 2.0 sounds like a solid 
> plan. I don't think any of the (Pending)DeprecationWarnings are much of 
> a public API. I've never seen them in the wild. 
> 
> /Markus 
> 
> On Mon, Jun 22, 2015 at 11:20:52AM -0400, Michael Manfre wrote: 
> >+1. I really don't like the idea of 2.x being odd. 
> > 
> >On Mon, Jun 22, 2015 at 10:33 AM, Loïc Bistuer  
> >wrote: 
> > 
> >> Just when we thought we had a winner... I'd like to make a final proposal. 
> >> 
> >> Instead of delaying adoption of SemVer to 3.0 we could do so in 2.0 by 
> >> introducing the 1.10 and 1.11LTS releases. 
> >> 
> >> The upside is that the new policy applies right away and we avoid the 
> >> oddball 2.0 and 2.1 releases. 
> >> 
> >> It's much less invasive than the previous idea of renaming 1.9 to 2.0, but 
> >> it still requires renaming PendingDeprecationWarnings in 1.8, and both 
> >> warnings in 1.9. 
> >> 
> >> What do you think? 
> >> 
> >> -- 
> >> Loïc 
> >> 
> >> > On Jun 17, 2015, at 08:47, Josh Smeaton  wrote: 
> >> > 
> >> > I'm also +1 on the proposal as it stands, and neutral on when the semver 
> >> versioning should begin. 
> >> > 
> >> > On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote: 
> >> > I'm +1 on the Google doc proposal and like Markus, I support relabeling 
> >> 1.9 to 2.0 to line the versions up with the new paradigm without the X.1 
> >> LTS oddball. 
> >> > 
> >> > Regards, 
> >> > Michael Manfre 
> >> > 
> >> > On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson  
> >> wrote: 
> >> > I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1, 
> >> 3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and we 
> >> sacrifice a little bit of strict semver, but it give some nice meaning to 
> >> the version numbers. 
> >> > 
> >> > 
> >> > On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote: 
> >> > Thanks Loïc, 
> >> > 
> >> > On 06/16/2015 01:15 AM, Loïc Bistuer wrote: 
> >> > > I've attempted to summarize the history of this thread. Note that I 
> >> > > marked as +1 any generally positive feedback towards a given 
> >> > > proposal, please correct if you feel misrepresented. 
> >> > > 
> >> > [snip] 
> >> > > 
> >> > > # Third iteration: 
> >> > > 
> >> > > 5/ Switching to Semantic Versioning 
> >> > > 
> >> > > Donald mentioned SemVer on IRC a few days ago. Since then various 
> >> > > proposal were made to reconcile it with our release policy. So far 
> >> > > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to 
> >> > > various proposals in that direction but I don't think we have yet 
> >> > > reached consensus on a specific one. Tim updated the Google doc to 
> >> > > reflect my latest proposal, so including me that's 2 formal +1 for 
> >> > > it, but I'd say we should wait for at least a couple more votes 
> >> > > before taking it to the technical board. 
> >> > > 
> >> > > Refs: - http://semver.org/ - Carl's analysis 
> >> > > 
> >> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J 
> >> > > 
> >> > > 
> >> > - Ryan's proposals 
> >> > 
> >> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ 
> >> > > - Loïc's proposal 
> >> > > 
> >> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ 
> >> > 
> >> > FWIW, I am also +1 on your proposal, as currently documented in the 
> >> > Google doc. 
> >> > 
> >> > I was trying to come up with a proposal where LTS == major release for 
> >> > the sake of argument, since it seemed like that was intuitive to at 
> >> > least some people, but it's not worth the required lengthening of 
> >> > deprecation paths. Your proposal is much better. (And it does make some 
> >> > intuitive sense for the _last_ minor release in a major series to be LTS 
> >> > rather than the first). 
> >> > 
> >> > 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-develop...@googlegroups.com. 
> >> > To post to this group, send email to django-d...@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/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com
> >>  
> >> 

Re: 1.9 release planning

[Collin Anderson]

People import the warning in order to silence them, right?

On Monday, June 22, 2015 at 1:19:51 PM UTC-4, Markus Holtermann wrote:
>
> +1 -- Going with 1.8, 1.9, 1.10, 1.11 (LTS), 2.0 sounds like a solid 
> plan. I don't think any of the (Pending)DeprecationWarnings are much of 
> a public API. I've never seen them in the wild. 
>
> /Markus 
>
> On Mon, Jun 22, 2015 at 11:20:52AM -0400, Michael Manfre wrote: 
> >+1. I really don't like the idea of 2.x being odd. 
> > 
> >On Mon, Jun 22, 2015 at 10:33 AM, Loïc Bistuer  > 
> >wrote: 
> > 
> >> Just when we thought we had a winner... I'd like to make a final 
> proposal. 
> >> 
> >> Instead of delaying adoption of SemVer to 3.0 we could do so in 2.0 by 
> >> introducing the 1.10 and 1.11LTS releases. 
> >> 
> >> The upside is that the new policy applies right away and we avoid the 
> >> oddball 2.0 and 2.1 releases. 
> >> 
> >> It's much less invasive than the previous idea of renaming 1.9 to 2.0, 
> but 
> >> it still requires renaming PendingDeprecationWarnings in 1.8, and both 
> >> warnings in 1.9. 
> >> 
> >> What do you think? 
> >> 
> >> -- 
> >> Loïc 
> >> 
> >> > On Jun 17, 2015, at 08:47, Josh Smeaton  > wrote: 
> >> > 
> >> > I'm also +1 on the proposal as it stands, and neutral on when the 
> semver 
> >> versioning should begin. 
> >> > 
> >> > On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote: 
> >> > I'm +1 on the Google doc proposal and like Markus, I support 
> relabeling 
> >> 1.9 to 2.0 to line the versions up with the new paradigm without the 
> X.1 
> >> LTS oddball. 
> >> > 
> >> > Regards, 
> >> > Michael Manfre 
> >> > 
> >> > On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson  
>
> >> wrote: 
> >> > I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1, 
> >> 3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and we 
> >> sacrifice a little bit of strict semver, but it give some nice meaning 
> to 
> >> the version numbers. 
> >> > 
> >> > 
> >> > On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote: 
> >> > Thanks Loïc, 
> >> > 
> >> > On 06/16/2015 01:15 AM, Loïc Bistuer wrote: 
> >> > > I've attempted to summarize the history of this thread. Note that I 
> >> > > marked as +1 any generally positive feedback towards a given 
> >> > > proposal, please correct if you feel misrepresented. 
> >> > > 
> >> > [snip] 
> >> > > 
> >> > > # Third iteration: 
> >> > > 
> >> > > 5/ Switching to Semantic Versioning 
> >> > > 
> >> > > Donald mentioned SemVer on IRC a few days ago. Since then various 
> >> > > proposal were made to reconcile it with our release policy. So far 
> >> > > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback 
> to 
> >> > > various proposals in that direction but I don't think we have yet 
> >> > > reached consensus on a specific one. Tim updated the Google doc to 
> >> > > reflect my latest proposal, so including me that's 2 formal +1 for 
> >> > > it, but I'd say we should wait for at least a couple more votes 
> >> > > before taking it to the technical board. 
> >> > > 
> >> > > Refs: - http://semver.org/ - Carl's analysis 
> >> > > 
> >> 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J 
> >> > > 
> >> > > 
> >> > - Ryan's proposals 
> >> > 
> >> 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ 
> >> > > - Loïc's proposal 
> >> > > 
> >> 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ 
> >> > 
> >> > FWIW, I am also +1 on your proposal, as currently documented in the 
> >> > Google doc. 
> >> > 
> >> > I was trying to come up with a proposal where LTS == major release 
> for 
> >> > the sake of argument, since it seemed like that was intuitive to at 
> >> > least some people, but it's not worth the required lengthening of 
> >> > deprecation paths. Your proposal is much better. (And it does make 
> some 
> >> > intuitive sense for the _last_ minor release in a major series to be 
> LTS 
> >> > rather than the first). 
> >> > 
> >> > 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-develop...@googlegroups.com. 
> >> > To post to this group, send email to django-d...@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/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com
>  
> >> . 
> >> > 
> >> > For more options, visit https://groups.google.com/d/optout. 
> >> > 
> >> > 
> >> > 
> >> > -- 
> >> > GPG Fingerprint: 74DE D158 BAD0 EDF8 
> >> > keybase.io/manfre 
> >> > 
> >> > -- 
> >> > You received this 

Re: 1.9 release planning

[Markus Holtermann]

+1 -- Going with 1.8, 1.9, 1.10, 1.11 (LTS), 2.0 sounds like a solid
plan. I don't think any of the (Pending)DeprecationWarnings are much of
a public API. I've never seen them in the wild.

/Markus

On Mon, Jun 22, 2015 at 11:20:52AM -0400, Michael Manfre wrote:

+1. I really don't like the idea of 2.x being odd.

On Mon, Jun 22, 2015 at 10:33 AM, Loïc Bistuer 
wrote:


Just when we thought we had a winner... I'd like to make a final proposal.

Instead of delaying adoption of SemVer to 3.0 we could do so in 2.0 by
introducing the 1.10 and 1.11LTS releases.

The upside is that the new policy applies right away and we avoid the
oddball 2.0 and 2.1 releases.

It's much less invasive than the previous idea of renaming 1.9 to 2.0, but
it still requires renaming PendingDeprecationWarnings in 1.8, and both
warnings in 1.9.

What do you think?

--
Loïc

> On Jun 17, 2015, at 08:47, Josh Smeaton  wrote:
>
> I'm also +1 on the proposal as it stands, and neutral on when the semver
versioning should begin.
>
> On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote:
> I'm +1 on the Google doc proposal and like Markus, I support relabeling
1.9 to 2.0 to line the versions up with the new paradigm without the X.1
LTS oddball.
>
> Regards,
> Michael Manfre
>
> On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson 
wrote:
> I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1,
3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and we
sacrifice a little bit of strict semver, but it give some nice meaning to
the version numbers.
>
>
> On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote:
> Thanks Loïc,
>
> On 06/16/2015 01:15 AM, Loïc Bistuer wrote:
> > I've attempted to summarize the history of this thread. Note that I
> > marked as +1 any generally positive feedback towards a given
> > proposal, please correct if you feel misrepresented.
> >
> [snip]
> >
> > # Third iteration:
> >
> > 5/ Switching to Semantic Versioning
> >
> > Donald mentioned SemVer on IRC a few days ago. Since then various
> > proposal were made to reconcile it with our release policy. So far
> > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to
> > various proposals in that direction but I don't think we have yet
> > reached consensus on a specific one. Tim updated the Google doc to
> > reflect my latest proposal, so including me that's 2 formal +1 for
> > it, but I'd say we should wait for at least a couple more votes
> > before taking it to the technical board.
> >
> > Refs: - http://semver.org/ - Carl's analysis
> >
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
> >
> >
> - Ryan's proposals
>
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
> > - Loïc's proposal
> >
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ
>
> FWIW, I am also +1 on your proposal, as currently documented in the
> Google doc.
>
> I was trying to come up with a proposal where LTS == major release for
> the sake of argument, since it seemed like that was intuitive to at
> least some people, but it's not worth the required lengthening of
> deprecation paths. Your proposal is much better. (And it does make some
> intuitive sense for the _last_ minor release in a major series to be LTS
> rather than the first).
>
> 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-develop...@googlegroups.com.
> To post to this group, send email to django-d...@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/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com
.
>
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> GPG Fingerprint: 74DE D158 BAD0 EDF8
> keybase.io/manfre
>
> --
> 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/79aae5a5-58dd-4f05-a6dd-35685e06ebb5%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 

Re: 1.9 release planning

[Michael Manfre]

+1. I really don't like the idea of 2.x being odd.

On Mon, Jun 22, 2015 at 10:33 AM, Loïc Bistuer 
wrote:

> Just when we thought we had a winner... I'd like to make a final proposal.
>
> Instead of delaying adoption of SemVer to 3.0 we could do so in 2.0 by
> introducing the 1.10 and 1.11LTS releases.
>
> The upside is that the new policy applies right away and we avoid the
> oddball 2.0 and 2.1 releases.
>
> It's much less invasive than the previous idea of renaming 1.9 to 2.0, but
> it still requires renaming PendingDeprecationWarnings in 1.8, and both
> warnings in 1.9.
>
> What do you think?
>
> --
> Loïc
>
> > On Jun 17, 2015, at 08:47, Josh Smeaton  wrote:
> >
> > I'm also +1 on the proposal as it stands, and neutral on when the semver
> versioning should begin.
> >
> > On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote:
> > I'm +1 on the Google doc proposal and like Markus, I support relabeling
> 1.9 to 2.0 to line the versions up with the new paradigm without the X.1
> LTS oddball.
> >
> > Regards,
> > Michael Manfre
> >
> > On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson 
> wrote:
> > I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1,
> 3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and we
> sacrifice a little bit of strict semver, but it give some nice meaning to
> the version numbers.
> >
> >
> > On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote:
> > Thanks Loïc,
> >
> > On 06/16/2015 01:15 AM, Loïc Bistuer wrote:
> > > I've attempted to summarize the history of this thread. Note that I
> > > marked as +1 any generally positive feedback towards a given
> > > proposal, please correct if you feel misrepresented.
> > >
> > [snip]
> > >
> > > # Third iteration:
> > >
> > > 5/ Switching to Semantic Versioning
> > >
> > > Donald mentioned SemVer on IRC a few days ago. Since then various
> > > proposal were made to reconcile it with our release policy. So far
> > > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to
> > > various proposals in that direction but I don't think we have yet
> > > reached consensus on a specific one. Tim updated the Google doc to
> > > reflect my latest proposal, so including me that's 2 formal +1 for
> > > it, but I'd say we should wait for at least a couple more votes
> > > before taking it to the technical board.
> > >
> > > Refs: - http://semver.org/ - Carl's analysis
> > >
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
> > >
> > >
> > - Ryan's proposals
> >
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
> > > - Loïc's proposal
> > >
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ
> >
> > FWIW, I am also +1 on your proposal, as currently documented in the
> > Google doc.
> >
> > I was trying to come up with a proposal where LTS == major release for
> > the sake of argument, since it seemed like that was intuitive to at
> > least some people, but it's not worth the required lengthening of
> > deprecation paths. Your proposal is much better. (And it does make some
> > intuitive sense for the _last_ minor release in a major series to be LTS
> > rather than the first).
> >
> > 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-develop...@googlegroups.com.
> > To post to this group, send email to django-d...@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/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com
> .
> >
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> >
> > --
> > GPG Fingerprint: 74DE D158 BAD0 EDF8
> > keybase.io/manfre
> >
> > --
> > 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/79aae5a5-58dd-4f05-a6dd-35685e06ebb5%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 

Re: 1.9 release planning

[Tim Graham]

It's okay with me. I don't think RemovedInDjango18Warning is much of a 
public API, but we can mention it's renaming in the minor release notes 
just in case.

On Monday, June 22, 2015 at 10:33:47 AM UTC-4, Loïc Bistuer wrote:
>
> Just when we thought we had a winner... I'd like to make a final proposal. 
>
> Instead of delaying adoption of SemVer to 3.0 we could do so in 2.0 by 
> introducing the 1.10 and 1.11LTS releases. 
>
> The upside is that the new policy applies right away and we avoid the 
> oddball 2.0 and 2.1 releases. 
>
> It's much less invasive than the previous idea of renaming 1.9 to 2.0, but 
> it still requires renaming PendingDeprecationWarnings in 1.8, and both 
> warnings in 1.9. 
>
> What do you think? 
>
> -- 
> Loïc 
>
> > On Jun 17, 2015, at 08:47, Josh Smeaton  > wrote: 
> > 
> > I'm also +1 on the proposal as it stands, and neutral on when the semver 
> versioning should begin. 
> > 
> > On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote: 
> > I'm +1 on the Google doc proposal and like Markus, I support relabeling 
> 1.9 to 2.0 to line the versions up with the new paradigm without the X.1 
> LTS oddball. 
> > 
> > Regards, 
> > Michael Manfre 
> > 
> > On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson  
> wrote: 
> > I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1, 
> 3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and we 
> sacrifice a little bit of strict semver, but it give some nice meaning to 
> the version numbers. 
> > 
> > 
> > On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote: 
> > Thanks Loïc, 
> > 
> > On 06/16/2015 01:15 AM, Loïc Bistuer wrote: 
> > > I've attempted to summarize the history of this thread. Note that I 
> > > marked as +1 any generally positive feedback towards a given 
> > > proposal, please correct if you feel misrepresented. 
> > > 
> > [snip] 
> > > 
> > > # Third iteration: 
> > > 
> > > 5/ Switching to Semantic Versioning 
> > > 
> > > Donald mentioned SemVer on IRC a few days ago. Since then various 
> > > proposal were made to reconcile it with our release policy. So far 
> > > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to 
> > > various proposals in that direction but I don't think we have yet 
> > > reached consensus on a specific one. Tim updated the Google doc to 
> > > reflect my latest proposal, so including me that's 2 formal +1 for 
> > > it, but I'd say we should wait for at least a couple more votes 
> > > before taking it to the technical board. 
> > > 
> > > Refs: - http://semver.org/ - Carl's analysis 
> > > 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J 
> > > 
> > > 
> > - Ryan's proposals 
> > 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ 
> > > - Loïc's proposal 
> > > 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ 
> > 
> > FWIW, I am also +1 on your proposal, as currently documented in the 
> > Google doc. 
> > 
> > I was trying to come up with a proposal where LTS == major release for 
> > the sake of argument, since it seemed like that was intuitive to at 
> > least some people, but it's not worth the required lengthening of 
> > deprecation paths. Your proposal is much better. (And it does make some 
> > intuitive sense for the _last_ minor release in a major series to be LTS 
> > rather than the first). 
> > 
> > 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-develop...@googlegroups.com. 
> > To post to this group, send email to django-d...@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/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com.
>  
>
> > 
> > For more options, visit https://groups.google.com/d/optout. 
> > 
> > 
> > 
> > -- 
> > GPG Fingerprint: 74DE D158 BAD0 EDF8 
> > keybase.io/manfre 
> > 
> > -- 
> > 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-develop...@googlegroups.com . 
> > To post to this group, send email to django-d...@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/79aae5a5-58dd-4f05-a6dd-35685e06ebb5%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 

Re: 1.9 release planning

[Loïc Bistuer]

Just when we thought we had a winner... I'd like to make a final proposal.

Instead of delaying adoption of SemVer to 3.0 we could do so in 2.0 by 
introducing the 1.10 and 1.11LTS releases.

The upside is that the new policy applies right away and we avoid the oddball 
2.0 and 2.1 releases.

It's much less invasive than the previous idea of renaming 1.9 to 2.0, but it 
still requires renaming PendingDeprecationWarnings in 1.8, and both warnings in 
1.9.

What do you think?

-- 
Loïc

> On Jun 17, 2015, at 08:47, Josh Smeaton  wrote:
> 
> I'm also +1 on the proposal as it stands, and neutral on when the semver 
> versioning should begin.
> 
> On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote:
> I'm +1 on the Google doc proposal and like Markus, I support relabeling 1.9 
> to 2.0 to line the versions up with the new paradigm without the X.1 LTS 
> oddball.
> 
> Regards,
> Michael Manfre
> 
> On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson  wrote:
> I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1, 3.2 
> LTS, 4.0, etc.) LTS is the final of a major version number, and we sacrifice 
> a little bit of strict semver, but it give some nice meaning to the version 
> numbers.
> 
> 
> On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote:
> Thanks Loïc, 
> 
> On 06/16/2015 01:15 AM, Loïc Bistuer wrote: 
> > I've attempted to summarize the history of this thread. Note that I 
> > marked as +1 any generally positive feedback towards a given 
> > proposal, please correct if you feel misrepresented. 
> > 
> [snip] 
> > 
> > # Third iteration: 
> > 
> > 5/ Switching to Semantic Versioning 
> > 
> > Donald mentioned SemVer on IRC a few days ago. Since then various 
> > proposal were made to reconcile it with our release policy. So far 
> > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to 
> > various proposals in that direction but I don't think we have yet 
> > reached consensus on a specific one. Tim updated the Google doc to 
> > reflect my latest proposal, so including me that's 2 formal +1 for 
> > it, but I'd say we should wait for at least a couple more votes 
> > before taking it to the technical board. 
> > 
> > Refs: - http://semver.org/ - Carl's analysis 
> > https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J 
> > 
> > 
> - Ryan's proposals 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ 
> > - Loïc's proposal 
> > https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ 
> 
> FWIW, I am also +1 on your proposal, as currently documented in the 
> Google doc. 
> 
> I was trying to come up with a proposal where LTS == major release for 
> the sake of argument, since it seemed like that was intuitive to at 
> least some people, but it's not worth the required lengthening of 
> deprecation paths. Your proposal is much better. (And it does make some 
> intuitive sense for the _last_ minor release in a major series to be LTS 
> rather than the first). 
> 
> 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-develop...@googlegroups.com.
> To post to this group, send email to django-d...@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/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com.
> 
> For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> -- 
> GPG Fingerprint: 74DE D158 BAD0 EDF8
> keybase.io/manfre
> 
> -- 
> 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/79aae5a5-58dd-4f05-a6dd-35685e06ebb5%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 

Re: 1.9 release planning

[Josh Smeaton]

I'm also +1 on the proposal as it stands, and neutral on when the semver 
versioning should begin.

On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote:
>
> I'm +1 on the Google doc proposal and like Markus, I support relabeling 
> 1.9 to 2.0 to line the versions up with the new paradigm without the X.1 
> LTS oddball.
>
> Regards,
> Michael Manfre
>
> On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson  > wrote:
>
>> I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1, 3.2 
>> LTS, 4.0, etc.) LTS is the final of a major version number, and we 
>> sacrifice a little bit of strict semver, but it give some nice meaning to 
>> the version numbers.
>>
>>
>> On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote:
>>>
>>> Thanks Loïc, 
>>>
>>> On 06/16/2015 01:15 AM, Loïc Bistuer wrote: 
>>> > I've attempted to summarize the history of this thread. Note that I 
>>> > marked as +1 any generally positive feedback towards a given 
>>> > proposal, please correct if you feel misrepresented. 
>>> > 
>>> [snip] 
>>> > 
>>> > # Third iteration: 
>>> > 
>>> > 5/ Switching to Semantic Versioning 
>>> > 
>>> > Donald mentioned SemVer on IRC a few days ago. Since then various 
>>> > proposal were made to reconcile it with our release policy. So far 
>>> > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to 
>>> > various proposals in that direction but I don't think we have yet 
>>> > reached consensus on a specific one. Tim updated the Google doc to 
>>> > reflect my latest proposal, so including me that's 2 formal +1 for 
>>> > it, but I'd say we should wait for at least a couple more votes 
>>> > before taking it to the technical board. 
>>> > 
>>> > Refs: - http://semver.org/ - Carl's analysis 
>>> > 
>>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J 
>>> > 
>>> > 
>>> - Ryan's proposals 
>>>
>>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ 
>>> > - Loïc's proposal 
>>> > 
>>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ 
>>>
>>> FWIW, I am also +1 on your proposal, as currently documented in the 
>>> Google doc. 
>>>
>>> I was trying to come up with a proposal where LTS == major release for 
>>> the sake of argument, since it seemed like that was intuitive to at 
>>> least some people, but it's not worth the required lengthening of 
>>> deprecation paths. Your proposal is much better. (And it does make some 
>>> intuitive sense for the _last_ minor release in a major series to be LTS 
>>> rather than the first). 
>>>
>>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@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/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> GPG Fingerprint: 74DE D158 BAD0 EDF8
> keybase.io/manfre
>  

-- 
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/79aae5a5-58dd-4f05-a6dd-35685e06ebb5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Michael Manfre]

I'm +1 on the Google doc proposal and like Markus, I support relabeling 1.9
to 2.0 to line the versions up with the new paradigm without the X.1 LTS
oddball.

Regards,
Michael Manfre

On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson 
wrote:

> I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1, 3.2
> LTS, 4.0, etc.) LTS is the final of a major version number, and we
> sacrifice a little bit of strict semver, but it give some nice meaning to
> the version numbers.
>
>
> On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote:
>>
>> Thanks Loïc,
>>
>> On 06/16/2015 01:15 AM, Loïc Bistuer wrote:
>> > I've attempted to summarize the history of this thread. Note that I
>> > marked as +1 any generally positive feedback towards a given
>> > proposal, please correct if you feel misrepresented.
>> >
>> [snip]
>> >
>> > # Third iteration:
>> >
>> > 5/ Switching to Semantic Versioning
>> >
>> > Donald mentioned SemVer on IRC a few days ago. Since then various
>> > proposal were made to reconcile it with our release policy. So far
>> > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to
>> > various proposals in that direction but I don't think we have yet
>> > reached consensus on a specific one. Tim updated the Google doc to
>> > reflect my latest proposal, so including me that's 2 formal +1 for
>> > it, but I'd say we should wait for at least a couple more votes
>> > before taking it to the technical board.
>> >
>> > Refs: - http://semver.org/ - Carl's analysis
>> >
>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
>> >
>> >
>> - Ryan's proposals
>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
>> > - Loïc's proposal
>> >
>> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ
>>
>> FWIW, I am also +1 on your proposal, as currently documented in the
>> Google doc.
>>
>> I was trying to come up with a proposal where LTS == major release for
>> the sake of argument, since it seemed like that was intuitive to at
>> least some people, but it's not worth the required lengthening of
>> deprecation paths. Your proposal is much better. (And it does make some
>> intuitive sense for the _last_ minor release in a major series to be LTS
>> rather than the first).
>>
>> 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/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre

-- 
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/CAGdCwBvLzcDHTfFQebw0gbJ%3DodJMxcVcYoiUXQ2HOpqicym3SA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Collin Anderson]

I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1, 3.2 
LTS, 4.0, etc.) LTS is the final of a major version number, and we 
sacrifice a little bit of strict semver, but it give some nice meaning to 
the version numbers.

On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote:
>
> Thanks Loïc, 
>
> On 06/16/2015 01:15 AM, Loïc Bistuer wrote: 
> > I've attempted to summarize the history of this thread. Note that I 
> > marked as +1 any generally positive feedback towards a given 
> > proposal, please correct if you feel misrepresented. 
> > 
> [snip] 
> > 
> > # Third iteration: 
> > 
> > 5/ Switching to Semantic Versioning 
> > 
> > Donald mentioned SemVer on IRC a few days ago. Since then various 
> > proposal were made to reconcile it with our release policy. So far 
> > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to 
> > various proposals in that direction but I don't think we have yet 
> > reached consensus on a specific one. Tim updated the Google doc to 
> > reflect my latest proposal, so including me that's 2 formal +1 for 
> > it, but I'd say we should wait for at least a couple more votes 
> > before taking it to the technical board. 
> > 
> > Refs: - http://semver.org/ - Carl's analysis 
> > 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J 
> > 
> > 
> - Ryan's proposals 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ 
> > - Loïc's proposal 
> > 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ 
>
> FWIW, I am also +1 on your proposal, as currently documented in the 
> Google doc. 
>
> I was trying to come up with a proposal where LTS == major release for 
> the sake of argument, since it seemed like that was intuitive to at 
> least some people, but it's not worth the required lengthening of 
> deprecation paths. Your proposal is much better. (And it does make some 
> intuitive sense for the _last_ minor release in a major series to be LTS 
> rather than the first). 
>
> 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/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Carl Meyer]

Thanks Loïc,

On 06/16/2015 01:15 AM, Loïc Bistuer wrote:
> I've attempted to summarize the history of this thread. Note that I
> marked as +1 any generally positive feedback towards a given
> proposal, please correct if you feel misrepresented.
> 
[snip]
>
> # Third iteration:
> 
> 5/ Switching to Semantic Versioning
> 
> Donald mentioned SemVer on IRC a few days ago. Since then various
> proposal were made to reconcile it with our release policy. So far
> Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to
> various proposals in that direction but I don't think we have yet
> reached consensus on a specific one. Tim updated the Google doc to
> reflect my latest proposal, so including me that's 2 formal +1 for
> it, but I'd say we should wait for at least a couple more votes
> before taking it to the technical board.
> 
> Refs: - http://semver.org/ - Carl's analysis
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
>
> 
- Ryan's proposals
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
> - Loïc's proposal
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ

FWIW, I am also +1 on your proposal, as currently documented in the
Google doc.

I was trying to come up with a proposal where LTS == major release for
the sake of argument, since it seemed like that was intuitive to at
least some people, but it's not worth the required lengthening of
deprecation paths. Your proposal is much better. (And it does make some
intuitive sense for the _last_ minor release in a major series to be LTS
rather than the first).

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/55804D47.5030802%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: 1.9 release planning

[Markus Holtermann]

Thanks Loic, that helps A LOT!

I'm +1 on a semver or semver-ish policy. I don't have a favorite of the
proposed. And I'm +-0 on changing e.g. 1.9 to 2.0 or whatever is
required to match the new release policy.

/Markus

On Tue, Jun 16, 2015 at 02:15:59PM +0700, Loïc Bistuer wrote:

I've attempted to summarize the history of this thread. Note that I marked as 
+1 any generally positive feedback towards a given proposal, please correct if 
you feel misrepresented.


# First iteration:

1/ Release every 8 months (previously undefined).

2/ LTS every 3rd releases (previously undefined but effectively 1.8 is the 4th 
release after 1.4). Thanks to point 1/ it means one LTS release every two years.

3/ LTS releases are supported for 3 years (previously undefined). Combined with 
points 1/ and 2/ this gives us 1 year of support overlap between 2 LTS 
(currently we committed as an afterthought to 6 months overlap between 1.4 LTS 
and 1.8 LTS).

Core +1: Tim, Marc, Markus, Collin, Aymeric, Loïc


# Second iteration:

4/ Deprecation shims must appear in a LTS release before being dropped.

So far this is the only real change in the policy, first iteration only 
adjusted and/or pinned variables.

In practice, thanks to point 2/, this only requires one exception to our 
current policy: features deprecated in the release *immediately following* an 
LTS have to be supported for 1 extra release. (e.g 1.9 
PendingDeprecationWarning, 2.0 PendingDeprecationWarning, 2.1 
DeprecationWarning). In return this makes it easier for 3rd-party apps to 
straddle 2 LTS releases without writing their own shims (provided their code 
runs without deprecation warnings on the oldest LTS).

Core +1: Collin, Carl, Tim, Anssi, Michael, Loïc

Refs:
- django-compat thread 
(https://groups.google.com/d/topic/django-developers/ASnZ5Uyol6Y/discussion)
- Collin's proposal 
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/hou67ofj3EYJ and 
the 7 following responses.


# Third iteration:

5/ Switching to Semantic Versioning

Donald mentioned SemVer on IRC a few days ago. Since then various proposal were 
made to reconcile it with our release policy. So far Collin, Carl, Loïc, Tim, 
and Josh have expressed positive feedback to various proposals in that 
direction but I don't think we have yet reached consensus on a specific one. 
Tim updated the Google doc to reflect my latest proposal, so including me 
that's 2 formal +1 for it, but I'd say we should wait for at least a couple 
more votes before taking it to the technical board.

Refs:
- http://semver.org/
- Carl's analysis 
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
- Ryan's proposals 
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
- Loïc's proposal 
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ

Cheers

--
Loïc


On Jun 16, 2015, at 02:37, Aymeric Augustin 
 wrote:

If we're approaching consensus, could a kind soul put together a final proposal 
and submit it to the technical board, along with the main arguments or 
alternatives? I'm finding it difficult to follow this 50-message thread... 
Thanks :-)


--
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/B8FE1DF4-1542-465B-B3DE-A7CA0DE5C3BB%40gmail.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/20150616124159.GF25232%40pyler.local.
For more options, visit https://groups.google.com/d/optout.


pgpYsNc2aWalH.pgp
Description: PGP signature

Re: 1.9 release planning

[Loïc Bistuer]

I've attempted to summarize the history of this thread. Note that I marked as 
+1 any generally positive feedback towards a given proposal, please correct if 
you feel misrepresented.


# First iteration:

1/ Release every 8 months (previously undefined).

2/ LTS every 3rd releases (previously undefined but effectively 1.8 is the 4th 
release after 1.4). Thanks to point 1/ it means one LTS release every two years.

3/ LTS releases are supported for 3 years (previously undefined). Combined with 
points 1/ and 2/ this gives us 1 year of support overlap between 2 LTS 
(currently we committed as an afterthought to 6 months overlap between 1.4 LTS 
and 1.8 LTS).

Core +1: Tim, Marc, Markus, Collin, Aymeric, Loïc


# Second iteration:

4/ Deprecation shims must appear in a LTS release before being dropped.

So far this is the only real change in the policy, first iteration only 
adjusted and/or pinned variables.

In practice, thanks to point 2/, this only requires one exception to our 
current policy: features deprecated in the release *immediately following* an 
LTS have to be supported for 1 extra release. (e.g 1.9 
PendingDeprecationWarning, 2.0 PendingDeprecationWarning, 2.1 
DeprecationWarning). In return this makes it easier for 3rd-party apps to 
straddle 2 LTS releases without writing their own shims (provided their code 
runs without deprecation warnings on the oldest LTS).

Core +1: Collin, Carl, Tim, Anssi, Michael, Loïc

Refs:
- django-compat thread 
(https://groups.google.com/d/topic/django-developers/ASnZ5Uyol6Y/discussion)
- Collin's proposal 
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/hou67ofj3EYJ and 
the 7 following responses.


# Third iteration:

5/ Switching to Semantic Versioning

Donald mentioned SemVer on IRC a few days ago. Since then various proposal were 
made to reconcile it with our release policy. So far Collin, Carl, Loïc, Tim, 
and Josh have expressed positive feedback to various proposals in that 
direction but I don't think we have yet reached consensus on a specific one. 
Tim updated the Google doc to reflect my latest proposal, so including me 
that's 2 formal +1 for it, but I'd say we should wait for at least a couple 
more votes before taking it to the technical board.

Refs:
- http://semver.org/
- Carl's analysis 
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
- Ryan's proposals 
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
- Loïc's proposal 
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ

Cheers

-- 
Loïc

> On Jun 16, 2015, at 02:37, Aymeric Augustin 
>  wrote:
> 
> If we're approaching consensus, could a kind soul put together a final 
> proposal and submit it to the technical board, along with the main arguments 
> or alternatives? I'm finding it difficult to follow this 50-message thread... 
> Thanks :-)

-- 
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/B8FE1DF4-1542-465B-B3DE-A7CA0DE5C3BB%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Tim Graham]

The Google doc has been evolving: 
https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing

On Monday, June 15, 2015 at 3:37:16 PM UTC-4, Aymeric Augustin wrote:
>
> Le 15 juin 2015 à 15:54, Loïc Bistuer  
> a écrit : 
> > 
> > I'm -0 (borderline -1) on that proposal. I don't think we should 
> compromise on our historical commitment of deprecating over 2 releases 
>
> I'm in the same camp as Loïc on this specific point. 
>
> If we're approaching consensus, could a kind soul put together a final 
> proposal and submit it to the technical board, along with the main 
> arguments or alternatives? I'm finding it difficult to follow this 
> 50-message thread... Thanks :-) 
>
> -- 
> 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/dd4b36ba-baae-4e8a-a9f8-322f4af08eaf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Aymeric Augustin]

Le 15 juin 2015 à 15:54, Loïc Bistuer  a écrit :
> 
> I'm -0 (borderline -1) on that proposal. I don't think we should compromise 
> on our historical commitment of deprecating over 2 releases

I'm in the same camp as Loïc on this specific point.

If we're approaching consensus, could a kind soul put together a final proposal 
and submit it to the technical board, along with the main arguments or 
alternatives? I'm finding it difficult to follow this 50-message thread... 
Thanks :-)

-- 
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/1A9872EF-5D1A-4621-972B-F657C076D272%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Ryan Hiebert]

Given the negative reaction to quick deprecation of LTS releases, I also now 
most prefer Loïc's proposal. It's semver with a little extra to help folks out.

I'd also most prefer seeing 1.9 being changed to 2.0 if this proposal were 
accepted, but that is not a strong opinion given that I am not familiar with 
the pain involved with renaming the deprecation warnings.

Sent from my iPhone

> On Jun 15, 2015, at 08:54, Loïc Bistuer  wrote:
> 
> I'm -0 (borderline -1) on that proposal. I don't think we should compromise 
> on our historical commitment of deprecating over 2 releases, especially since 
> it's aligned with the policy of Python itself and much of the ecosystem.
> 
> It should be as easy as possible for 3rd-party apps to straddle 2 LTS 
> releases, but when it comes to user projects we should make it as easy as 
> possible to keep up with the latest stable. Sticking to LTS versions deprive 
> you from up to three years of innovation in Django, IMO it's only appropriate 
> for projects in maintenance mode. Our current policy allows you to take 
> advantage of new features right away while having almost a year and a half to 
> deal with deprecations.
> 
> The only additional overhead of my counterproposal is an extra 8 months of 
> support for features deprecated in an LTS for a total of 16 months. 
> Considering non-LTS releases require between 16 months and 24 months I think 
> it's very manageable.
> 
> Regarding timeline for adoption, I prefer switching right away but I'm also 
> happy with a 2.1 > 3.0 switch, so whatever is more popular. Also it shouldn't 
> get lost because regardless of the SemVer decision we'll need to update 
> RemovedInDjango21Warning in master.
> 
>> On Jun 15, 2015, at 19:37, Josh Smeaton  wrote:
>> 
>> I really like Ryan's second proposal (quoting here again):
>> 
>> 2.2 - 0 mos - (LTS) No features dropped 
>> 3.0 - 8 mos - All deprecations, including the LTS deprecations, are removed 
>> 3.1 - 16 mos - No features dropped 
>> 3.2 - 24 mos - (LTS) No features dropped 
>> 4.0 - 32 mos - All deprecations, including the LTS deprecations, are removed 
>> 4.1 - 40 mos - No features dropped 
>> 4.2 - 48 mos - (LTS) No features dropped
>> 
>> It'll mean that the maximum time a feature can be supported while 
>> deprecating is 2 years. The shortest it can be supported is a single release 
>> if the deprecation is made in an LTS - which I think is fine because the LTS 
>> is supported for 3 years anyway. It perfectly adheres to semver (which is a 
>> nice property, but not the be-all and end-all), and still allows libraries 
>> to straddle two LTS releases. Is there a good reason we couldn't use this 
>> model?
>> 
>> And I agree with Tim that changing the version numbers of already planned 
>> releases is not a good idea. The version naming can wait until the current 
>> Removed* warnings are gone - and timing it with the Python 3 only release 
>> sounds like a fairly good motivation to bump the major version and continue 
>> with semver from there. Provided we remember/document the plan :)
>> 
>> On Sunday, 14 June 2015 09:58:41 UTC+10, Tim Graham wrote:
>> Of course RemovedInDjango19Warning is also in 1.7 and a lot of docs 
>> reference Django 1.9. I'm not enthusiastic about updating all that.
>> 
>>> On Sunday, June 14, 2015 at 1:43:50 AM UTC+2, Loïc Bistuer wrote:
>>> 
>>> On Jun 13, 2015, at 20:43, Tim Graham  wrote: 
>>> 
>>> I don't have a strong opinion either way on semver, but I think it's a bit 
>>> late to rebrand 1.9 as 2.0 considering we've release code and docs with 
>>> reference to "RemovedInDjango19Warning". Do you have any thoughts on that? 
>>> We could plan the change for after the next LTS (2.1 -> 3.0) to correspond 
>>> with the cutover to Python 3.
>> 
>> 
>> Currently we have: 
>> 
>> 1.8: 
>>RemovedInDjango19Warning(DeprecationWarning) - Deprecations from 1.7 
>>RemovedInDjango20Warning(PendingDeprecationWarning) - Deprecations from 
>> 1.8 
>> 
>> master: 
>>RemovedInDjango20Warning(DeprecationWarning) - Deprecations from 1.8 
>>RemovedInDjango21Warning(PendingDeprecationWarning) - Deprecations from 
>> master 
>> 
>> In any case, implementing the new policy will require updating warnings from 
>> master: RemovedInDjango21Warning needs to become either 
>> RemovedInDjango22Warning or RemovedInDjango31Warning with the switch to 
>> SemVer. 
>> 
>> The question is whether it's too invasive to update warnings in a 1.8 patch 
>> release. If we ensure that RemovedInDjango19Warning remains importable by 
>> aliasing it to RemovedInDjango20Warning(DeprecationWarning), I think it's 
>> compatible enough not to delay implementing the scheme by another two years, 
>> especially considering how warnings are normally used. But if we want to be 
>> super cautious we could just leave the code as it is and document the 
>> problem in the 1.8 release notes, after all we are 

Re: 1.9 release planning

[Loïc Bistuer]

I'm -0 (borderline -1) on that proposal. I don't think we should compromise on 
our historical commitment of deprecating over 2 releases, especially since it's 
aligned with the policy of Python itself and much of the ecosystem.

It should be as easy as possible for 3rd-party apps to straddle 2 LTS releases, 
but when it comes to user projects we should make it as easy as possible to 
keep up with the latest stable. Sticking to LTS versions deprive you from up to 
three years of innovation in Django, IMO it's only appropriate for projects in 
maintenance mode. Our current policy allows you to take advantage of new 
features right away while having almost a year and a half to deal with 
deprecations.

The only additional overhead of my counterproposal is an extra 8 months of 
support for features deprecated in an LTS for a total of 16 months. Considering 
non-LTS releases require between 16 months and 24 months I think it's very 
manageable.

Regarding timeline for adoption, I prefer switching right away but I'm also 
happy with a 2.1 > 3.0 switch, so whatever is more popular. Also it shouldn't 
get lost because regardless of the SemVer decision we'll need to update 
RemovedInDjango21Warning in master.

> On Jun 15, 2015, at 19:37, Josh Smeaton  wrote:
> 
> I really like Ryan's second proposal (quoting here again):
> 
> 2.2 - 0 mos - (LTS) No features dropped 
> 3.0 - 8 mos - All deprecations, including the LTS deprecations, are removed 
> 3.1 - 16 mos - No features dropped 
> 3.2 - 24 mos - (LTS) No features dropped 
> 4.0 - 32 mos - All deprecations, including the LTS deprecations, are removed 
> 4.1 - 40 mos - No features dropped 
> 4.2 - 48 mos - (LTS) No features dropped
> 
> It'll mean that the maximum time a feature can be supported while deprecating 
> is 2 years. The shortest it can be supported is a single release if the 
> deprecation is made in an LTS - which I think is fine because the LTS is 
> supported for 3 years anyway. It perfectly adheres to semver (which is a nice 
> property, but not the be-all and end-all), and still allows libraries to 
> straddle two LTS releases. Is there a good reason we couldn't use this model?
> 
> And I agree with Tim that changing the version numbers of already planned 
> releases is not a good idea. The version naming can wait until the current 
> Removed* warnings are gone - and timing it with the Python 3 only release 
> sounds like a fairly good motivation to bump the major version and continue 
> with semver from there. Provided we remember/document the plan :)
> 
> On Sunday, 14 June 2015 09:58:41 UTC+10, Tim Graham wrote:
> Of course RemovedInDjango19Warning is also in 1.7 and a lot of docs reference 
> Django 1.9. I'm not enthusiastic about updating all that.
> 
> On Sunday, June 14, 2015 at 1:43:50 AM UTC+2, Loïc Bistuer wrote:
> 
> > On Jun 13, 2015, at 20:43, Tim Graham  wrote: 
> > 
> > I don't have a strong opinion either way on semver, but I think it's a bit 
> > late to rebrand 1.9 as 2.0 considering we've release code and docs with 
> > reference to "RemovedInDjango19Warning". Do you have any thoughts on that? 
> > We could plan the change for after the next LTS (2.1 -> 3.0) to correspond 
> > with the cutover to Python 3. 
> 
> 
> Currently we have: 
> 
> 1.8: 
> RemovedInDjango19Warning(DeprecationWarning) - Deprecations from 1.7 
> RemovedInDjango20Warning(PendingDeprecationWarning) - Deprecations from 
> 1.8 
> 
> master: 
> RemovedInDjango20Warning(DeprecationWarning) - Deprecations from 1.8 
> RemovedInDjango21Warning(PendingDeprecationWarning) - Deprecations from 
> master 
> 
> In any case, implementing the new policy will require updating warnings from 
> master: RemovedInDjango21Warning needs to become either 
> RemovedInDjango22Warning or RemovedInDjango31Warning with the switch to 
> SemVer. 
> 
> The question is whether it's too invasive to update warnings in a 1.8 patch 
> release. If we ensure that RemovedInDjango19Warning remains importable by 
> aliasing it to RemovedInDjango20Warning(DeprecationWarning), I think it's 
> compatible enough not to delay implementing the scheme by another two years, 
> especially considering how warnings are normally used. But if we want to be 
> super cautious we could just leave the code as it is and document the problem 
> in the 1.8 release notes, after all we are extending the lifespan of the 
> shims (at least in appearance) which isn't as problematic as if we were 
> shortening it. 
> 
> -- 
> Loïc 
> 
> 
> -- 
> 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 

Re: 1.9 release planning

[Josh Smeaton]

I really like Ryan's second proposal (quoting here again):

2.2 - 0 mos - (LTS) No features dropped 
> *3.0 - 8 mos - All deprecations, including the LTS deprecations, are 
> removed *
> 3.1 - 16 mos - No features dropped 
> 3.2 - 24 mos - (LTS) No features dropped 
> *4.0 - 32 mos - All deprecations, including the LTS deprecations, are 
> removed *
> 4.1 - 40 mos - No features dropped 
> 4.2 - 48 mos - (LTS) No features dropped


It'll mean that the maximum time a feature can be supported while 
deprecating is 2 years. The shortest it can be supported is a single 
release if the deprecation is made in an LTS - which I think is fine 
because the LTS is supported for 3 years anyway. It perfectly adheres to 
semver (which is a nice property, but not the be-all and end-all), and 
still allows libraries to straddle two LTS releases. Is there a good reason 
we couldn't use this model?

And I agree with Tim that changing the version numbers of already planned 
releases is not a good idea. The version naming can wait until the current 
Removed* warnings are gone - and timing it with the Python 3 only release 
sounds like a fairly good motivation to bump the major version and continue 
with semver from there. Provided we remember/document the plan :)

On Sunday, 14 June 2015 09:58:41 UTC+10, Tim Graham wrote:
>
> Of course RemovedInDjango19Warning is also in 1.7 and a lot of docs 
> reference Django 1.9. I'm not enthusiastic about updating all that.
>
> On Sunday, June 14, 2015 at 1:43:50 AM UTC+2, Loïc Bistuer wrote:
>>
>>
>> > On Jun 13, 2015, at 20:43, Tim Graham  wrote: 
>> > 
>> > I don't have a strong opinion either way on semver, but I think it's a 
>> bit late to rebrand 1.9 as 2.0 considering we've release code and docs with 
>> reference to "RemovedInDjango19Warning". Do you have any thoughts on that? 
>> We could plan the change for after the next LTS (2.1 -> 3.0) to correspond 
>> with the cutover to Python 3. 
>>
>>
>> Currently we have: 
>>
>> 1.8: 
>> RemovedInDjango19Warning(DeprecationWarning) - Deprecations from 1.7 
>> RemovedInDjango20Warning(PendingDeprecationWarning) - Deprecations 
>> from 1.8 
>>
>> master: 
>> RemovedInDjango20Warning(DeprecationWarning) - Deprecations from 1.8 
>> RemovedInDjango21Warning(PendingDeprecationWarning) - Deprecations 
>> from master 
>>
>> In any case, implementing the new policy will require updating warnings 
>> from master: RemovedInDjango21Warning needs to become either 
>> RemovedInDjango22Warning or RemovedInDjango31Warning with the switch to 
>> SemVer. 
>>
>> The question is whether it's too invasive to update warnings in a 1.8 
>> patch release. If we ensure that RemovedInDjango19Warning remains 
>> importable by aliasing it to RemovedInDjango20Warning(DeprecationWarning), 
>> I think it's compatible enough not to delay implementing the scheme by 
>> another two years, especially considering how warnings are normally used. 
>> But if we want to be super cautious we could just leave the code as it is 
>> and document the problem in the 1.8 release notes, after all we are 
>> extending the lifespan of the shims (at least in appearance) which isn't as 
>> problematic as if we were shortening it. 
>>
>> -- 
>> Loïc 
>>
>>

-- 
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/4c636d6d-4365-48dc-932a-5a67cec44a51%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Tim Graham]

Of course RemovedInDjango19Warning is also in 1.7 and a lot of docs 
reference Django 1.9. I'm not enthusiastic about updating all that.

On Sunday, June 14, 2015 at 1:43:50 AM UTC+2, Loïc Bistuer wrote:
>
>
> > On Jun 13, 2015, at 20:43, Tim Graham  
> wrote: 
> > 
> > I don't have a strong opinion either way on semver, but I think it's a 
> bit late to rebrand 1.9 as 2.0 considering we've release code and docs with 
> reference to "RemovedInDjango19Warning". Do you have any thoughts on that? 
> We could plan the change for after the next LTS (2.1 -> 3.0) to correspond 
> with the cutover to Python 3. 
>
>
> Currently we have: 
>
> 1.8: 
> RemovedInDjango19Warning(DeprecationWarning) - Deprecations from 1.7 
> RemovedInDjango20Warning(PendingDeprecationWarning) - Deprecations 
> from 1.8 
>
> master: 
> RemovedInDjango20Warning(DeprecationWarning) - Deprecations from 1.8 
> RemovedInDjango21Warning(PendingDeprecationWarning) - Deprecations 
> from master 
>
> In any case, implementing the new policy will require updating warnings 
> from master: RemovedInDjango21Warning needs to become either 
> RemovedInDjango22Warning or RemovedInDjango31Warning with the switch to 
> SemVer. 
>
> The question is whether it's too invasive to update warnings in a 1.8 
> patch release. If we ensure that RemovedInDjango19Warning remains 
> importable by aliasing it to RemovedInDjango20Warning(DeprecationWarning), 
> I think it's compatible enough not to delay implementing the scheme by 
> another two years, especially considering how warnings are normally used. 
> But if we want to be super cautious we could just leave the code as it is 
> and document the problem in the 1.8 release notes, after all we are 
> extending the lifespan of the shims (at least in appearance) which isn't as 
> problematic as if we were shortening it. 
>
> -- 
> Loïc 
>
>

-- 
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/1213b5f4-e7f2-4326-9962-13afa313e554%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Loïc Bistuer]

> On Jun 13, 2015, at 20:43, Tim Graham  wrote:
> 
> I don't have a strong opinion either way on semver, but I think it's a bit 
> late to rebrand 1.9 as 2.0 considering we've release code and docs with 
> reference to "RemovedInDjango19Warning". Do you have any thoughts on that? We 
> could plan the change for after the next LTS (2.1 -> 3.0) to correspond with 
> the cutover to Python 3.


Currently we have:

1.8:
RemovedInDjango19Warning(DeprecationWarning) - Deprecations from 1.7
RemovedInDjango20Warning(PendingDeprecationWarning) - Deprecations from 1.8

master:
RemovedInDjango20Warning(DeprecationWarning) - Deprecations from 1.8
RemovedInDjango21Warning(PendingDeprecationWarning) - Deprecations from 
master

In any case, implementing the new policy will require updating warnings from 
master: RemovedInDjango21Warning needs to become either 
RemovedInDjango22Warning or RemovedInDjango31Warning with the switch to SemVer.

The question is whether it's too invasive to update warnings in a 1.8 patch 
release. If we ensure that RemovedInDjango19Warning remains importable by 
aliasing it to RemovedInDjango20Warning(DeprecationWarning), I think it's 
compatible enough not to delay implementing the scheme by another two years, 
especially considering how warnings are normally used. But if we want to be 
super cautious we could just leave the code as it is and document the problem 
in the 1.8 release notes, after all we are extending the lifespan of the shims 
(at least in appearance) which isn't as problematic as if we were shortening it.

-- 
Loïc

-- 
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/3B8CE3F8-F39C-49AF-A5B5-7A252E9F7CAD%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Tim Graham]

I don't have a strong opinion either way on semver, but I think it's a bit 
late to rebrand 1.9 as 2.0 considering we've release code and docs with 
reference to "RemovedInDjango19Warning". Do you have any thoughts on that? 
We could plan the change for after the next LTS (2.1 -> 3.0) to correspond 
with the cutover to Python 3.

On Saturday, June 13, 2015 at 11:05:49 AM UTC-4, Loïc Bistuer wrote:
>
> Quoting semver.org: 
>
> Given a version number MAJOR.MINOR.PATCH, increment the: 
>
> MAJOR version when you make incompatible API changes, 
> MINOR version when you add functionality in a backwards-compatible manner, 
> and 
> PATCH version when you make backwards-compatible bug fixes. 
>
> We are only breaking the first rule with backwards incompatible changes 
> that don't undergo deprecations, but considering that we do our very best 
> to avoid these, I think it's fair enough to just document it as a caveat. 
>
> SemVer makes it easier to see at a glance how long you are supposed to 
> support Django versions as a 3rd-party app author and where you can rely on 
> shims. It also brings more visibility to our efforts to ease straddle two 
> LTS versions (supporting shims from LTS+1 for 1 additional release). I 
> think it's enough to justify adopting it even if we aren't "pure" in its 
> implementation. 
>
> -- 
> Loïc 
>
> > On Jun 13, 2015, at 13:03, Tim Graham  
> wrote: 
> > 
> > I'm happy to give it a try if there's consensus that it might help. On 
> the other hand, this doesn't account for the inevitable backwards 
> incompatible changes that come along. For example, someone in the survey 
> said "Django 1.7 is a hard change for clients and it should have been 2.0 
> so that they realize what the jump means." Unfortunately, it's impossible 
> to anticipate when features like that might come along and I'm not sure 
> we'd want to delay features so that they don't first appear in an LTS 
> release (at least, this would be a pretty big change in Django development 
> and slow down innovation in my view). 
> > 
> > On Saturday, June 13, 2015 at 6:25:44 AM UTC-4, Loïc Bistuer wrote: 
> > I think Collin's proposal can match semver without additional overhead 
> when LTS are the final minor releases of any given major branch. 
> > 
> > 1.8 LTS 
> > 2.0 (Drop features from 1.7) 
> > 2.1 (Drop features from 1.8 LTS) 
> > 2.2 LTS 
> > 3.0 (Drop features from 2.0, 2.1) 
> > 3.1 (Drop features from 2.2 LTS) 
> > 3.2 LTS 
> > 
> > That way we can say that features are never removed until the next major 
> release. 
> > 
> > Features deprecated in a LTS leak onto x.1 releases but that's fine (1 
> release deprecations are a no-go IMO), we can document it as "deprecations 
> from a major branch will be either loud or gone in the following major 
> branch". 
> > 
> > -- 
> > Loïc 
> > 
> > > On Jun 13, 2015, at 04:16, Tim Graham  wrote: 
> > > 
> > > I'm still in favor of "Collin's proposal." You'll need to convince me 
> that keeping deprecations around longer is worth having somewhat meaningful 
> version numbers, but I'm not sure I really consider dropping deprecation 
> shims as "incompatible API changes" that justify a major version bump. For 
> example, if I run on 2.X (whatever is right before the version where 
> features are dropped) without deprecation warnings, then upgrading to 3.0 
> isn't any more difficult than other upgrades. It might be a nice touch to 
> call the version after the next LTS (2.1 under Collin's proposal) "3.0" 
> since it will drop Python 2 support, but it's not really important IMO 
> > > 
> > > On Friday, June 12, 2015 at 8:00:30 PM UTC-4, Ryan Hiebert wrote: 
> > > An alternative would be for the LTS to be the second-to-last minor 
> release before a major version bump. 
> > > 
> > > I'm also ignoring the transition for the sake of hypotheticals. I'm 
> also assuming that 2.2 is the last release of the 2.X series. 
> > > 
> > > 2.1 - 0 mos - (LTS) No features dropped 
> > > 2.2 - 8 mos - No features dropped 
> > > 3.0 - 16 mos - Drop all features deprecated by 2.1 
> > > 3.1 - 24 mos - (LTS) No features dropped 
> > > 3.2 - 32 mos - No features dropped 
> > > 4.0 - 40 mos - Drop all features deprecated by 3.1 
> > > 4.1 - 48 mos - (LTS) No features dropped 
> > > 
> > > It would mean that features deprecated before an LTS cannot be dropped 
> until two versions after the LTS, but it fits semver pretty well, and 
> doesn't speed up our deprecation removal. 
> > > 
> > > I'd argue for a major version dropping _all_ deprecated features. This 
> has the downside of speeding up our removal process in the last version of 
> a major release, and it encourages people to stay longer on the release 
> previous, since they won't have as much opportunity to fix them. It would 
> also mean that features deprecated in the last minor version of a major 
> version line would need to skip the pending deprecation warnings. 
> > > 
> > > If it were 

Re: 1.9 release planning

[Loïc Bistuer]

Quoting semver.org:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

We are only breaking the first rule with backwards incompatible changes that 
don't undergo deprecations, but considering that we do our very best to avoid 
these, I think it's fair enough to just document it as a caveat.

SemVer makes it easier to see at a glance how long you are supposed to support 
Django versions as a 3rd-party app author and where you can rely on shims. It 
also brings more visibility to our efforts to ease straddle two LTS versions 
(supporting shims from LTS+1 for 1 additional release). I think it's enough to 
justify adopting it even if we aren't "pure" in its implementation.

-- 
Loïc

> On Jun 13, 2015, at 13:03, Tim Graham  wrote:
> 
> I'm happy to give it a try if there's consensus that it might help. On the 
> other hand, this doesn't account for the inevitable backwards incompatible 
> changes that come along. For example, someone in the survey said "Django 1.7 
> is a hard change for clients and it should have been 2.0 so that they realize 
> what the jump means." Unfortunately, it's impossible to anticipate when 
> features like that might come along and I'm not sure we'd want to delay 
> features so that they don't first appear in an LTS release (at least, this 
> would be a pretty big change in Django development and slow down innovation 
> in my view).
> 
> On Saturday, June 13, 2015 at 6:25:44 AM UTC-4, Loïc Bistuer wrote:
> I think Collin's proposal can match semver without additional overhead when 
> LTS are the final minor releases of any given major branch. 
> 
> 1.8 LTS 
> 2.0 (Drop features from 1.7) 
> 2.1 (Drop features from 1.8 LTS) 
> 2.2 LTS 
> 3.0 (Drop features from 2.0, 2.1) 
> 3.1 (Drop features from 2.2 LTS) 
> 3.2 LTS 
> 
> That way we can say that features are never removed until the next major 
> release. 
> 
> Features deprecated in a LTS leak onto x.1 releases but that's fine (1 
> release deprecations are a no-go IMO), we can document it as "deprecations 
> from a major branch will be either loud or gone in the following major 
> branch". 
> 
> -- 
> Loïc 
> 
> > On Jun 13, 2015, at 04:16, Tim Graham  wrote: 
> > 
> > I'm still in favor of "Collin's proposal." You'll need to convince me that 
> > keeping deprecations around longer is worth having somewhat meaningful 
> > version numbers, but I'm not sure I really consider dropping deprecation 
> > shims as "incompatible API changes" that justify a major version bump. For 
> > example, if I run on 2.X (whatever is right before the version where 
> > features are dropped) without deprecation warnings, then upgrading to 3.0 
> > isn't any more difficult than other upgrades. It might be a nice touch to 
> > call the version after the next LTS (2.1 under Collin's proposal) "3.0" 
> > since it will drop Python 2 support, but it's not really important IMO 
> > 
> > On Friday, June 12, 2015 at 8:00:30 PM UTC-4, Ryan Hiebert wrote: 
> > An alternative would be for the LTS to be the second-to-last minor release 
> > before a major version bump. 
> > 
> > I'm also ignoring the transition for the sake of hypotheticals. I'm also 
> > assuming that 2.2 is the last release of the 2.X series. 
> > 
> > 2.1 - 0 mos - (LTS) No features dropped 
> > 2.2 - 8 mos - No features dropped 
> > 3.0 - 16 mos - Drop all features deprecated by 2.1 
> > 3.1 - 24 mos - (LTS) No features dropped 
> > 3.2 - 32 mos - No features dropped 
> > 4.0 - 40 mos - Drop all features deprecated by 3.1 
> > 4.1 - 48 mos - (LTS) No features dropped 
> > 
> > It would mean that features deprecated before an LTS cannot be dropped 
> > until two versions after the LTS, but it fits semver pretty well, and 
> > doesn't speed up our deprecation removal. 
> > 
> > I'd argue for a major version dropping _all_ deprecated features. This has 
> > the downside of speeding up our removal process in the last version of a 
> > major release, and it encourages people to stay longer on the release 
> > previous, since they won't have as much opportunity to fix them. It would 
> > also mean that features deprecated in the last minor version of a major 
> > version line would need to skip the pending deprecation warnings. 
> > 
> > If it were acceptable to do that, then I'd argue for the LTS to be the 
> > _last_ in a major version line, rather than the second-to-last. That would 
> > probably be my overall preferred, though I do recognize the previously 
> > mentioned drawbacks. Anything deprecated in an LTS in that case would skip 
> > the pending deprecation warning, and go straight to the deprecation 
> > warning. The deprecation timeline would then look like this: 
> > 
> > 2.2 - 0 mos - (LTS) No features dropped 
> > 3.0 - 8 mos - All 

Re: 1.9 release planning

[Tim Graham]

I'm happy to give it a try if there's consensus that it might help. On the 
other hand, this doesn't account for the inevitable backwards incompatible 
changes that come along. For example, someone in the survey said "Django 
1.7 is a hard change for clients and it should have been 2.0 so that they 
realize what the jump means." Unfortunately, it's impossible to anticipate 
when features like that might come along and I'm not sure we'd want to 
delay features so that they don't first appear in an LTS release (at least, 
this would be a pretty big change in Django development and slow down 
innovation in my view).

On Saturday, June 13, 2015 at 6:25:44 AM UTC-4, Loïc Bistuer wrote:
>
> I think Collin's proposal can match semver without additional overhead 
> when LTS are the final minor releases of any given major branch. 
>
> 1.8 LTS 
> 2.0 (Drop features from 1.7) 
> 2.1 (Drop features from 1.8 LTS) 
> 2.2 LTS 
> 3.0 (Drop features from 2.0, 2.1) 
> 3.1 (Drop features from 2.2 LTS) 
> 3.2 LTS 
>
> That way we can say that features are never removed until the next major 
> release. 
>
> Features deprecated in a LTS leak onto x.1 releases but that's fine (1 
> release deprecations are a no-go IMO), we can document it as "deprecations 
> from a major branch will be either loud or gone in the following major 
> branch". 
>
> -- 
> Loïc 
>
> > On Jun 13, 2015, at 04:16, Tim Graham  
> wrote: 
> > 
> > I'm still in favor of "Collin's proposal." You'll need to convince me 
> that keeping deprecations around longer is worth having somewhat meaningful 
> version numbers, but I'm not sure I really consider dropping deprecation 
> shims as "incompatible API changes" that justify a major version bump. For 
> example, if I run on 2.X (whatever is right before the version where 
> features are dropped) without deprecation warnings, then upgrading to 3.0 
> isn't any more difficult than other upgrades. It might be a nice touch to 
> call the version after the next LTS (2.1 under Collin's proposal) "3.0" 
> since it will drop Python 2 support, but it's not really important IMO 
> > 
> > On Friday, June 12, 2015 at 8:00:30 PM UTC-4, Ryan Hiebert wrote: 
> > An alternative would be for the LTS to be the second-to-last minor 
> release before a major version bump. 
> > 
> > I'm also ignoring the transition for the sake of hypotheticals. I'm also 
> assuming that 2.2 is the last release of the 2.X series. 
> > 
> > 2.1 - 0 mos - (LTS) No features dropped 
> > 2.2 - 8 mos - No features dropped 
> > 3.0 - 16 mos - Drop all features deprecated by 2.1 
> > 3.1 - 24 mos - (LTS) No features dropped 
> > 3.2 - 32 mos - No features dropped 
> > 4.0 - 40 mos - Drop all features deprecated by 3.1 
> > 4.1 - 48 mos - (LTS) No features dropped 
> > 
> > It would mean that features deprecated before an LTS cannot be dropped 
> until two versions after the LTS, but it fits semver pretty well, and 
> doesn't speed up our deprecation removal. 
> > 
> > I'd argue for a major version dropping _all_ deprecated features. This 
> has the downside of speeding up our removal process in the last version of 
> a major release, and it encourages people to stay longer on the release 
> previous, since they won't have as much opportunity to fix them. It would 
> also mean that features deprecated in the last minor version of a major 
> version line would need to skip the pending deprecation warnings. 
> > 
> > If it were acceptable to do that, then I'd argue for the LTS to be the 
> _last_ in a major version line, rather than the second-to-last. That would 
> probably be my overall preferred, though I do recognize the previously 
> mentioned drawbacks. Anything deprecated in an LTS in that case would skip 
> the pending deprecation warning, and go straight to the deprecation 
> warning. The deprecation timeline would then look like this: 
> > 
> > 2.2 - 0 mos - (LTS) No features dropped 
> > 3.0 - 8 mos - All deprecations, including the LTS deprecations, are 
> removed 
> > 3.1 - 16 mos - No features dropped 
> > 3.2 - 24 mos - (LTS) No features dropped 
> > 4.0 - 32 mos - All deprecations, including the LTS deprecations, are 
> removed 
> > 4.1 - 40 mos - No features dropped 
> > 4.2 - 48 mos - (LTS) No features dropped 
> > 
> > 
> > I think those are probably the two best LTS support release schedules 
> that follow semver. 
> > 
> > Ryan 
> > 
> > -- 
> > 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-develop...@googlegroups.com . 
> > To post to this group, send email to django-d...@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/f887421b-c470-491f-b5f0-a12af397bfe1%40googlegroups.com.
>  
>
> 

Re: 1.9 release planning

[Loïc Bistuer]

I think Collin's proposal can match semver without additional overhead when LTS 
are the final minor releases of any given major branch.

1.8 LTS
2.0 (Drop features from 1.7)
2.1 (Drop features from 1.8 LTS)
2.2 LTS
3.0 (Drop features from 2.0, 2.1)
3.1 (Drop features from 2.2 LTS)
3.2 LTS

That way we can say that features are never removed until the next major 
release.

Features deprecated in a LTS leak onto x.1 releases but that's fine (1 release 
deprecations are a no-go IMO), we can document it as "deprecations from a major 
branch will be either loud or gone in the following major branch".

-- 
Loïc

> On Jun 13, 2015, at 04:16, Tim Graham  wrote:
> 
> I'm still in favor of "Collin's proposal." You'll need to convince me that 
> keeping deprecations around longer is worth having somewhat meaningful 
> version numbers, but I'm not sure I really consider dropping deprecation 
> shims as "incompatible API changes" that justify a major version bump. For 
> example, if I run on 2.X (whatever is right before the version where features 
> are dropped) without deprecation warnings, then upgrading to 3.0 isn't any 
> more difficult than other upgrades. It might be a nice touch to call the 
> version after the next LTS (2.1 under Collin's proposal) "3.0" since it will 
> drop Python 2 support, but it's not really important IMO
> 
> On Friday, June 12, 2015 at 8:00:30 PM UTC-4, Ryan Hiebert wrote:
> An alternative would be for the LTS to be the second-to-last minor release 
> before a major version bump. 
> 
> I'm also ignoring the transition for the sake of hypotheticals. I'm also 
> assuming that 2.2 is the last release of the 2.X series. 
> 
> 2.1 - 0 mos - (LTS) No features dropped 
> 2.2 - 8 mos - No features dropped 
> 3.0 - 16 mos - Drop all features deprecated by 2.1 
> 3.1 - 24 mos - (LTS) No features dropped 
> 3.2 - 32 mos - No features dropped 
> 4.0 - 40 mos - Drop all features deprecated by 3.1 
> 4.1 - 48 mos - (LTS) No features dropped 
> 
> It would mean that features deprecated before an LTS cannot be dropped until 
> two versions after the LTS, but it fits semver pretty well, and doesn't speed 
> up our deprecation removal. 
> 
> I'd argue for a major version dropping _all_ deprecated features. This has 
> the downside of speeding up our removal process in the last version of a 
> major release, and it encourages people to stay longer on the release 
> previous, since they won't have as much opportunity to fix them. It would 
> also mean that features deprecated in the last minor version of a major 
> version line would need to skip the pending deprecation warnings. 
> 
> If it were acceptable to do that, then I'd argue for the LTS to be the _last_ 
> in a major version line, rather than the second-to-last. That would probably 
> be my overall preferred, though I do recognize the previously mentioned 
> drawbacks. Anything deprecated in an LTS in that case would skip the pending 
> deprecation warning, and go straight to the deprecation warning. The 
> deprecation timeline would then look like this: 
> 
> 2.2 - 0 mos - (LTS) No features dropped 
> 3.0 - 8 mos - All deprecations, including the LTS deprecations, are removed 
> 3.1 - 16 mos - No features dropped 
> 3.2 - 24 mos - (LTS) No features dropped 
> 4.0 - 32 mos - All deprecations, including the LTS deprecations, are removed 
> 4.1 - 40 mos - No features dropped 
> 4.2 - 48 mos - (LTS) No features dropped 
> 
> 
> I think those are probably the two best LTS support release schedules that 
> follow semver. 
> 
> Ryan
> 
> -- 
> 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/f887421b-c470-491f-b5f0-a12af397bfe1%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/2A833F90-C4AA-449F-BF97-B0514FA4F210%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Tim Graham]

I'm still in favor of "Collin's proposal." You'll need to convince me that 
keeping deprecations around longer is worth having somewhat meaningful 
version numbers, but I'm not sure I really consider dropping deprecation 
shims as "incompatible API changes" that justify a major version bump. For 
example, if I run on 2.X (whatever is right before the version where 
features are dropped) without deprecation warnings, then upgrading to 3.0 
isn't any more difficult than other upgrades. It might be a nice touch to 
call the version after the next LTS (2.1 under Collin's proposal) "3.0" 
since it will drop Python 2 support, but it's not really important IMO

On Friday, June 12, 2015 at 8:00:30 PM UTC-4, Ryan Hiebert wrote:
>
> An alternative would be for the LTS to be the second-to-last minor release 
> before a major version bump. 
>
> I'm also ignoring the transition for the sake of hypotheticals. I'm also 
> assuming that 2.2 is the last release of the 2.X series. 
>
> 2.1 - 0 mos - (LTS) No features dropped 
> 2.2 - 8 mos - No features dropped 
> 3.0 - 16 mos - Drop all features deprecated by 2.1 
> 3.1 - 24 mos - (LTS) No features dropped 
> 3.2 - 32 mos - No features dropped 
> 4.0 - 40 mos - Drop all features deprecated by 3.1 
> 4.1 - 48 mos - (LTS) No features dropped 
>
> It would mean that features deprecated before an LTS cannot be dropped 
> until two versions after the LTS, but it fits semver pretty well, and 
> doesn't speed up our deprecation removal. 
>
> I'd argue for a major version dropping _all_ deprecated features. This has 
> the downside of speeding up our removal process in the last version of a 
> major release, and it encourages people to stay longer on the release 
> previous, since they won't have as much opportunity to fix them. It would 
> also mean that features deprecated in the last minor version of a major 
> version line would need to skip the pending deprecation warnings. 
>
> If it were acceptable to do that, then I'd argue for the LTS to be the 
> _last_ in a major version line, rather than the second-to-last. That would 
> probably be my overall preferred, though I do recognize the previously 
> mentioned drawbacks. Anything deprecated in an LTS in that case would skip 
> the pending deprecation warning, and go straight to the deprecation 
> warning. The deprecation timeline would then look like this: 
>
> 2.2 - 0 mos - (LTS) No features dropped 
> 3.0 - 8 mos - All deprecations, including the LTS deprecations, are 
> removed 
> 3.1 - 16 mos - No features dropped 
> 3.2 - 24 mos - (LTS) No features dropped 
> 4.0 - 32 mos - All deprecations, including the LTS deprecations, are 
> removed 
> 4.1 - 40 mos - No features dropped 
> 4.2 - 48 mos - (LTS) No features dropped 
>
>
> I think those are probably the two best LTS support release schedules that 
> follow semver. 
>
> Ryan

-- 
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/f887421b-c470-491f-b5f0-a12af397bfe1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Ryan Hiebert]

An alternative would be for the LTS to be the second-to-last minor release 
before a major version bump.

I'm also ignoring the transition for the sake of hypotheticals. I'm also 
assuming that 2.2 is the last release of the 2.X series.

2.1 - 0 mos - (LTS) No features dropped
2.2 - 8 mos - No features dropped
3.0 - 16 mos - Drop all features deprecated by 2.1
3.1 - 24 mos - (LTS) No features dropped
3.2 - 32 mos - No features dropped
4.0 - 40 mos - Drop all features deprecated by 3.1
4.1 - 48 mos - (LTS) No features dropped 

It would mean that features deprecated before an LTS cannot be dropped until 
two versions after the LTS, but it fits semver pretty well, and doesn't speed 
up our deprecation removal.

I'd argue for a major version dropping _all_ deprecated features. This has the 
downside of speeding up our removal process in the last version of a major 
release, and it encourages people to stay longer on the release previous, since 
they won't have as much opportunity to fix them. It would also mean that 
features deprecated in the last minor version of a major version line would 
need to skip the pending deprecation warnings.

If it were acceptable to do that, then I'd argue for the LTS to be the _last_ 
in a major version line, rather than the second-to-last. That would probably be 
my overall preferred, though I do recognize the previously mentioned drawbacks. 
Anything deprecated in an LTS in that case would skip the pending deprecation 
warning, and go straight to the deprecation warning. The deprecation timeline 
would then look like this:

2.2 - 0 mos - (LTS) No features dropped
3.0 - 8 mos - All deprecations, including the LTS deprecations, are removed
3.1 - 16 mos - No features dropped
3.2 - 24 mos - (LTS) No features dropped
4.0 - 32 mos - All deprecations, including the LTS deprecations, are removed
4.1 - 40 mos - No features dropped
4.2 - 48 mos - (LTS) No features dropped


I think those are probably the two best LTS support release schedules that 
follow semver.

Ryan

-- 
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/F36EA2A5-4D9F-489C-82B9-7AE4D93B258F%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Aymeric Augustin]

2015-06-12 18:58 GMT+02:00 Carl Meyer :

> I don't get the feeling that the core team is really ready to accept
>
that length of continued support for deprecated APIs.
>

Especially if the deprecation and removal is a pre-requisite for
implementing a new feature... I'm not writing code that I can't use
until 2020!

-- 
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-7mXTzJrVHy2wmN3ssxecUPYqxs5DN_CvOzDb%3D7DjirNw3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Carl Meyer]

Hi Matt,

On 06/11/2015 07:30 PM, Matt Austin wrote:
> On 11 June 2015 at 01:37, Collin Anderson  wrote:
>>
>> I'd propose something slightly different, that's very close to our current
>> deprecation timeline:
>> 1.8 (LTS): No features dropped.
>> 1.9: Dropped features deprecated in 1.5, 1.6, 1.7
>> 2.0: Dropped features deprecated in 1.8
>> 2.1 (LTS): No features dropped.
>> 2.2: Dropped features deprecated in 1.9, 2.0
>> 2.3: Dropped features deprecated in 2.1
>>
>> Seems to me features deprecated in an LTS are fair game to disappear in the
>> next LTS. This allows us to remove "dotted paths in reverse() and url()"
>> because that's deprecated in 1.8.
>>
>> If we can guarantee compatibility between LTSs, I think that would be a huge
>> win, at the cost of extending the removal of some deprecated features by one
>> release (8 months).
>>
> 
> Hi everyone,
> 
> Sorry to stick my nose in, but thought I might throw a potential
> spanner-in-the works with this release discussion, in regard to
> version naming.
> 
> I understand that the current version system doesn't have too much
> inherent meaning, and that 2.0 will come after 1.9 'just so we don't
> stay on 1.x forever'.
> 
> With a more structured release plan, and LTS releases, would it be
> worth considering LTS releases as 'major' version numbers, with
> regular releases and 'minor' version releases? It would be easier to
> identify LTS releases at a glance, and might provide more meaning to
> the versioning scheme?

I find this idea tempting too, but (as Collin indirectly pointed out)
the problem is that it flips semver on its head, which some people might
find surprising. Because in Collin's schedule it's the _LTS_ releases
where no APIs will be removed, whereas any non-LTS release might have
APIs removed.

Donald proposed in IRC that we could go with a standard
major/minor/bugfix semver approach, with the added guarantee that every
removed feature will be deprecated in one major release first (to
preserve the ability to straddle two major releases, or upgrade
major->major without hitting removed APIs). This is nice and simple and
conforms to semver, but it means that deprecated features would hang
around quite a bit longer.

Just for the sake of comparison and devils advocate, here's what a full
switch to semver could look like for Django (I'll hand-wave past the
transition and just start with a hypothetical 2.0 release, which is
major/"LTS"):

2.0 - 0 mos - "LTS"
2.1 - 8 mos - may add/deprecate features, but not remove
2.2 - 16 mos - may add/deprecate features, but not remove
3.0 - 24 mos - "LTS" - remove any features already deprecated in 2.0
3.1 - 32 mos - may add/deprecate features, but not remove
3.2 - 40 mos - may add/deprecate features, but not remove
4.0 - 48 mos - "LTS" - removes features deprecated in 2.1, 2.2, or 3.0
... etc ...

Just like in the current proposal, 2.0 would continue to receive 2.0.X
security releases until a year after 3.0 is released (thus for three
years, given no delays). 2.1 would receive bugfix releases until 2.2 is
released, and thereafter security releases until 3.0 is released. 2.2
would receive security releases until 3.1 is released. (This is just
like the current system.)

This scheme conforms to semver, and allows for no-breakage
straddling/upgrades from major(LTS) to major(LTS) release. The cost,
compared to the current proposal, is that a deprecated feature might
need to stick around _in master_ for almost four years (if it's
deprecated in e.g. 2.1 and then finally removed in 4.0). Whereas in
Collin's proposal, the longest a deprecated feature would ever stay in
master is about two years (e.g. from 1.9 to 2.1 in his schedule above).

I'll admit that the simplicity (and semantic version numbering) of this
scheme does grow on me, but I don't get the feeling that the core team
is really ready to accept that length of continued support for
deprecated APIs.

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/557B0FA6.1010605%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: 1.9 release planning

[Collin Anderson]

Hi Matt,

I was thinking about this too and it came up on IRC today. I think if we 
were to strictly go with something like semver, we'd end up with a 
numbering scheme like 2.0, 2.1 (LTS), 3.0, 4.0, 4.1 (LTS), 5.0, etc, 
because features can be removed in between LTSs (assuming they're marked as 
deprecated in the previous LTS).

Collin

On Thursday, June 11, 2015 at 9:31:08 PM UTC-4, Matt Austin wrote:
>
> On 11 June 2015 at 01:37, Collin Anderson  > wrote: 
> > 
> > I'd propose something slightly different, that's very close to our 
> current 
> > deprecation timeline: 
> > 1.8 (LTS): No features dropped. 
> > 1.9: Dropped features deprecated in 1.5, 1.6, 1.7 
> > 2.0: Dropped features deprecated in 1.8 
> > 2.1 (LTS): No features dropped. 
> > 2.2: Dropped features deprecated in 1.9, 2.0 
> > 2.3: Dropped features deprecated in 2.1 
> > 
> > Seems to me features deprecated in an LTS are fair game to disappear in 
> the 
> > next LTS. This allows us to remove "dotted paths in reverse() and url()" 
> > because that's deprecated in 1.8. 
> > 
> > If we can guarantee compatibility between LTSs, I think that would be a 
> huge 
> > win, at the cost of extending the removal of some deprecated features by 
> one 
> > release (8 months). 
> > 
>
> Hi everyone, 
>
> Sorry to stick my nose in, but thought I might throw a potential 
> spanner-in-the works with this release discussion, in regard to 
> version naming. 
>
> I understand that the current version system doesn't have too much 
> inherent meaning, and that 2.0 will come after 1.9 'just so we don't 
> stay on 1.x forever'. 
>
> With a more structured release plan, and LTS releases, would it be 
> worth considering LTS releases as 'major' version numbers, with 
> regular releases and 'minor' version releases? It would be easier to 
> identify LTS releases at a glance, and might provide more meaning to 
> the versioning scheme? 
>
> Feel free to shut this idea down if it's going to open a can-of-worms :) 
>
>
> Cheers, 
>
> -- 
> Matt 
>

-- 
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/43108c2b-e8f0-4d69-bb70-da3ac4c516ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Matt Austin]

On 11 June 2015 at 01:37, Collin Anderson  wrote:
>
> I'd propose something slightly different, that's very close to our current
> deprecation timeline:
> 1.8 (LTS): No features dropped.
> 1.9: Dropped features deprecated in 1.5, 1.6, 1.7
> 2.0: Dropped features deprecated in 1.8
> 2.1 (LTS): No features dropped.
> 2.2: Dropped features deprecated in 1.9, 2.0
> 2.3: Dropped features deprecated in 2.1
>
> Seems to me features deprecated in an LTS are fair game to disappear in the
> next LTS. This allows us to remove "dotted paths in reverse() and url()"
> because that's deprecated in 1.8.
>
> If we can guarantee compatibility between LTSs, I think that would be a huge
> win, at the cost of extending the removal of some deprecated features by one
> release (8 months).
>

Hi everyone,

Sorry to stick my nose in, but thought I might throw a potential
spanner-in-the works with this release discussion, in regard to
version naming.

I understand that the current version system doesn't have too much
inherent meaning, and that 2.0 will come after 1.9 'just so we don't
stay on 1.x forever'.

With a more structured release plan, and LTS releases, would it be
worth considering LTS releases as 'major' version numbers, with
regular releases and 'minor' version releases? It would be easier to
identify LTS releases at a glance, and might provide more meaning to
the versioning scheme?

Feel free to shut this idea down if it's going to open a can-of-worms :)


Cheers,

--
Matt

-- 
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/CACATwqQge_4Bx%2BctJFsf02uTyhu9gy4GMBaUHx23XUEY6yXCuw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Michael Manfre]

I like Colin's proposed schedule.

Regards,
Michael Manfre

On Thu, Jun 11, 2015 at 1:12 AM, Anssi Kääriäinen 
wrote:

> +1 to Collin's release schedule.
>
> This schedule should make it extremely easy to support "develop using
> latest release, maintain using latest LTS". With the above schedule if
> you started with 1.8 you are already on LTS. If you start with 1.9,
> you should have an easy upgrade path all the way till 2.1 which is
> LTS. Also upgrading from 1.8 to 2.1 should be easy enough if you
> didn't use any deprecated features when running on 1.8.
>
>  - Anssi
>
> On Thu, Jun 11, 2015 at 12:06 AM, Tim Graham  wrote:
> > Yep, I think Collin's schedule is it. I'm happy with that option and 3rd
> > party apps shouldn't need to add any compatibility shims to support 2
> > releases -- they just need to ensure they aren't using any deprecated
> APIs.
> >
> >
> > On Wednesday, June 10, 2015 at 3:48:39 PM UTC-4, Collin Anderson wrote:
> >>
> >> Hi Tim,
> >>
> >> What I mean is we could still make it easy to support both LTS releases,
> >> even if we drop features deprecated in 1.8 before the next LTS
> according to
> >> the normal release schedule. Right? Because apps wouldn't need to use
> those
> >> deprecated features to support both 1.8 and 2.1. We could drop them in
> 2.0
> >> like normal?
> >>
> >> I'm trying to lessen the increased maintenance burden of Loic's proposal
> >> while still making it possible to easily support both LTS releases.
> >>
> >> > For "maintenance costs" I am not worried about supported deprecated
> APIs
> >> > in old releases, only how long they stay around in master as that
> could be a
> >> > barrier to innovation.
> >> Right, so the cost would be an extra 8 months before removing features
> >> deprecated in 1.9 from master.
> >>
> >> Thanks,
> >> Collin
> >>
> >> On Wednesday, June 10, 2015 at 2:09:13 PM UTC-4, Tim Graham wrote:
> >>>
> >>> Collin, I'm not following your reasoning about why dropping features
> >>> deprecated in one LTS (e.g. 1.8) in the next LTS (e.g. 2.1; I think
> you made
> >>> a typo in your timeline putting it next to 2.0?) will make it possible
> to
> >>> easily support both LTS releases? That's the purpose of Loic's
> proposal I
> >>> believe.
> >>>
> >>> For "maintenance costs" I am not worried about supported deprecated
> APIs
> >>> in old releases, only how long they stay around in master as that
> could be a
> >>> barrier to innovation.
> >>>
> >>> On Wednesday, June 10, 2015 at 1:54:53 PM UTC-4, Collin Anderson wrote:
> 
>  On Friday, May 8, 2015 at 12:12:37 PM UTC-4, Carl Meyer wrote:
> >
> > And there is a significant added maintenance cost to my proposal
> > compared to yours. Dropping deprecated APIs in the release after an
> LTS
> > means we still have to support those APIs for three more years
> > (possibly
> > for four or five years after they were first deprecated). Dropping
> them
> > _in_ the LTS release shortens that window drastically.
> 
> 
>  If we release every 8 months, that means we normally support
> deprecated
>  features for 2 years. If we maintained LTS compatibility, then, yes,
> that
>  would mean "supporting" the APIs for more than 5 years after
> deprecation.
>  But to be clear, most of that time it's only security support for
> those
>  APIs, and the APIs are long gone from master. Right?
> 
>  Thanks,
>  Collin
> 
> 
>  On Wednesday, June 10, 2015 at 1:37:30 PM UTC-4, Collin Anderson
> wrote:
> >
> > Hi All,
> >
> > Here are some thoughts in reply to some of the comments in the
> > django-compat thread. I don't stick to the LTSs myself, but I've
> helped
> > maintain apps that have 1.4 compatibility.
> >
> > On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:
> >>
> >> 1.8 (LTS): No features dropped.
> >> 1.9: Dropped features deprecated in 1.4, 1.5, 1.6, 1.7
> >> 2.0: No features dropped.
> >> 2.1 (LTS): No features dropped.
> >> 2.2: Dropped features deprecated in 1.8, 1.9, 2.0
> >
> >
> > I'd propose something slightly different, that's very close to our
> > current deprecation timeline:
> > 1.8 (LTS): No features dropped.
> > 1.9: Dropped features deprecated in 1.5, 1.6, 1.7
> > 2.0: Dropped features deprecated in 1.8
> > 2.1 (LTS): No features dropped.
> > 2.2: Dropped features deprecated in 1.9, 2.0
> > 2.3: Dropped features deprecated in 2.1
> >
> > Seems to me features deprecated in an LTS are fair game to disappear
> in
> > the next LTS. This allows us to remove "dotted paths in reverse()
> and url()"
> > because that's deprecated in 1.8.
> >
> > If we can guarantee compatibility between LTSs, I think that would
> be a
> > huge win, at the cost of extending the removal of some deprecated
> features
> > by one release (8 months).
> >
> 

Re: 1.9 release planning

[Anssi Kääriäinen]

+1 to Collin's release schedule.

This schedule should make it extremely easy to support "develop using
latest release, maintain using latest LTS". With the above schedule if
you started with 1.8 you are already on LTS. If you start with 1.9,
you should have an easy upgrade path all the way till 2.1 which is
LTS. Also upgrading from 1.8 to 2.1 should be easy enough if you
didn't use any deprecated features when running on 1.8.

 - Anssi

On Thu, Jun 11, 2015 at 12:06 AM, Tim Graham  wrote:
> Yep, I think Collin's schedule is it. I'm happy with that option and 3rd
> party apps shouldn't need to add any compatibility shims to support 2
> releases -- they just need to ensure they aren't using any deprecated APIs.
>
>
> On Wednesday, June 10, 2015 at 3:48:39 PM UTC-4, Collin Anderson wrote:
>>
>> Hi Tim,
>>
>> What I mean is we could still make it easy to support both LTS releases,
>> even if we drop features deprecated in 1.8 before the next LTS according to
>> the normal release schedule. Right? Because apps wouldn't need to use those
>> deprecated features to support both 1.8 and 2.1. We could drop them in 2.0
>> like normal?
>>
>> I'm trying to lessen the increased maintenance burden of Loic's proposal
>> while still making it possible to easily support both LTS releases.
>>
>> > For "maintenance costs" I am not worried about supported deprecated APIs
>> > in old releases, only how long they stay around in master as that could be 
>> > a
>> > barrier to innovation.
>> Right, so the cost would be an extra 8 months before removing features
>> deprecated in 1.9 from master.
>>
>> Thanks,
>> Collin
>>
>> On Wednesday, June 10, 2015 at 2:09:13 PM UTC-4, Tim Graham wrote:
>>>
>>> Collin, I'm not following your reasoning about why dropping features
>>> deprecated in one LTS (e.g. 1.8) in the next LTS (e.g. 2.1; I think you made
>>> a typo in your timeline putting it next to 2.0?) will make it possible to
>>> easily support both LTS releases? That's the purpose of Loic's proposal I
>>> believe.
>>>
>>> For "maintenance costs" I am not worried about supported deprecated APIs
>>> in old releases, only how long they stay around in master as that could be a
>>> barrier to innovation.
>>>
>>> On Wednesday, June 10, 2015 at 1:54:53 PM UTC-4, Collin Anderson wrote:

 On Friday, May 8, 2015 at 12:12:37 PM UTC-4, Carl Meyer wrote:
>
> And there is a significant added maintenance cost to my proposal
> compared to yours. Dropping deprecated APIs in the release after an LTS
> means we still have to support those APIs for three more years
> (possibly
> for four or five years after they were first deprecated). Dropping them
> _in_ the LTS release shortens that window drastically.


 If we release every 8 months, that means we normally support deprecated
 features for 2 years. If we maintained LTS compatibility, then, yes, that
 would mean "supporting" the APIs for more than 5 years after deprecation.
 But to be clear, most of that time it's only security support for those
 APIs, and the APIs are long gone from master. Right?

 Thanks,
 Collin


 On Wednesday, June 10, 2015 at 1:37:30 PM UTC-4, Collin Anderson wrote:
>
> Hi All,
>
> Here are some thoughts in reply to some of the comments in the
> django-compat thread. I don't stick to the LTSs myself, but I've helped
> maintain apps that have 1.4 compatibility.
>
> On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:
>>
>> 1.8 (LTS): No features dropped.
>> 1.9: Dropped features deprecated in 1.4, 1.5, 1.6, 1.7
>> 2.0: No features dropped.
>> 2.1 (LTS): No features dropped.
>> 2.2: Dropped features deprecated in 1.8, 1.9, 2.0
>
>
> I'd propose something slightly different, that's very close to our
> current deprecation timeline:
> 1.8 (LTS): No features dropped.
> 1.9: Dropped features deprecated in 1.5, 1.6, 1.7
> 2.0: Dropped features deprecated in 1.8
> 2.1 (LTS): No features dropped.
> 2.2: Dropped features deprecated in 1.9, 2.0
> 2.3: Dropped features deprecated in 2.1
>
> Seems to me features deprecated in an LTS are fair game to disappear in
> the next LTS. This allows us to remove "dotted paths in reverse() and 
> url()"
> because that's deprecated in 1.8.
>
> If we can guarantee compatibility between LTSs, I think that would be a
> huge win, at the cost of extending the removal of some deprecated features
> by one release (8 months).
>
> Collin
>
> --
> 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 

Re: 1.9 release planning

[Tim Graham]

Yep, I think Collin's schedule is it. I'm happy with that option and 3rd 
party apps shouldn't need to add any compatibility shims to support 2 
releases -- they just need to ensure they aren't using any deprecated APIs.

On Wednesday, June 10, 2015 at 3:48:39 PM UTC-4, Collin Anderson wrote:
>
> Hi Tim,
>
> What I mean is we could still make it easy to support both LTS releases, 
> even if we drop features deprecated in 1.8 before the next LTS according to 
> the normal release schedule. Right? Because apps wouldn't need to use those 
> deprecated features to support both 1.8 and 2.1. We could drop them in 2.0 
> like normal?
>
> I'm trying to lessen the increased maintenance burden of Loic's proposal 
> while still making it possible to easily support both LTS releases.
>
> > For "maintenance costs" I am not worried about supported deprecated APIs 
> in old releases, only how long they stay around in master as that could be 
> a barrier to innovation.
> Right, so the cost would be an extra 8 months before removing features 
> deprecated in 1.9 from master.
>
> Thanks,
> Collin
>
> On Wednesday, June 10, 2015 at 2:09:13 PM UTC-4, Tim Graham wrote:
>>
>> Collin, I'm not following your reasoning about why dropping features 
>> deprecated in one LTS (e.g. 1.8) in the next LTS (e.g. 2.1; I think you 
>> made a typo in your timeline putting it next to 2.0?) will make it possible 
>> to easily support both LTS releases? That's the purpose of Loic's proposal 
>> I believe.
>>
>> For "maintenance costs" I am not worried about supported deprecated APIs 
>> in old releases, only how long they stay around in master as that could be 
>> a barrier to innovation.
>>
>> On Wednesday, June 10, 2015 at 1:54:53 PM UTC-4, Collin Anderson wrote:
>>>
>>> On Friday, May 8, 2015 at 12:12:37 PM UTC-4, Carl Meyer wrote:

 And there is a significant added maintenance cost to my proposal 
 compared to yours. Dropping deprecated APIs in the release after an LTS 
 means we still have to support those APIs for three more years 
 (possibly 
 for four or five years after they were first deprecated). Dropping them 
 _in_ the LTS release shortens that window drastically.
>>>
>>>
>>> If we release every 8 months, that means we normally support deprecated 
>>> features for 2 years. If we maintained LTS compatibility, then, yes, that 
>>> would mean "supporting" the APIs for more than 5 years after deprecation. 
>>> But to be clear, most of that time it's only security support for those 
>>> APIs, and the APIs are long gone from master. Right?
>>>
>>> Thanks,
>>> Collin
>>>
>>>
>>> On Wednesday, June 10, 2015 at 1:37:30 PM UTC-4, Collin Anderson wrote:

 Hi All,

 Here are some thoughts in reply to some of the comments in the 
 django-compat thread. I don't stick to the LTSs myself, but I've helped 
 maintain apps that have 1.4 compatibility.

 On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:
>
> 1.8 (LTS): No features dropped. 
> 1.9: Dropped features deprecated in 1.4, 1.5, 1.6, 1.7 
> 2.0: No features dropped. 
> 2.1 (LTS): No features dropped. 
> 2.2: Dropped features deprecated in 1.8, 1.9, 2.0 
>

 I'd propose something slightly different, that's very close to our 
 current deprecation timeline:
 1.8 (LTS): No features dropped.
 1.9: Dropped features deprecated in 1.5, 1.6, 1.7
 2.0: Dropped features deprecated in 1.8
 2.1 (LTS): No features dropped. 
 2.2: Dropped features deprecated in 1.9, 2.0
 2.3: Dropped features deprecated in 2.1

 Seems to me features deprecated in an LTS are fair game to disappear in 
 the next LTS. This allows us to remove "dotted paths in reverse() and 
 url()" because that's deprecated in 1.8.

 If we can guarantee compatibility between LTSs, I think that would be a 
 huge win, at the cost of extending the removal of some deprecated features 
 by one release (8 months). 

 Collin



-- 
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/bbc5256e-f5e9-445d-9d35-601a55568b30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Collin Anderson]

Hi Tim,

What I mean is we could still make it easy to support both LTS releases, 
even if we drop features deprecated in 1.8 before the next LTS according to 
the normal release schedule. Right? Because apps wouldn't need to use those 
deprecated features to support both 1.8 and 2.1. We could drop them in 2.0 
like normal?

I'm trying to lessen the increased maintenance burden of Loic's proposal 
while still making it possible to easily support both LTS releases.

> For "maintenance costs" I am not worried about supported deprecated APIs 
in old releases, only how long they stay around in master as that could be 
a barrier to innovation.
Right, so the cost would be an extra 8 months before removing features 
deprecated in 1.9 from master.

Thanks,
Collin

On Wednesday, June 10, 2015 at 2:09:13 PM UTC-4, Tim Graham wrote:
>
> Collin, I'm not following your reasoning about why dropping features 
> deprecated in one LTS (e.g. 1.8) in the next LTS (e.g. 2.1; I think you 
> made a typo in your timeline putting it next to 2.0?) will make it possible 
> to easily support both LTS releases? That's the purpose of Loic's proposal 
> I believe.
>
> For "maintenance costs" I am not worried about supported deprecated APIs 
> in old releases, only how long they stay around in master as that could be 
> a barrier to innovation.
>
> On Wednesday, June 10, 2015 at 1:54:53 PM UTC-4, Collin Anderson wrote:
>>
>> On Friday, May 8, 2015 at 12:12:37 PM UTC-4, Carl Meyer wrote:
>>>
>>> And there is a significant added maintenance cost to my proposal 
>>> compared to yours. Dropping deprecated APIs in the release after an LTS 
>>> means we still have to support those APIs for three more years (possibly 
>>> for four or five years after they were first deprecated). Dropping them 
>>> _in_ the LTS release shortens that window drastically.
>>
>>
>> If we release every 8 months, that means we normally support deprecated 
>> features for 2 years. If we maintained LTS compatibility, then, yes, that 
>> would mean "supporting" the APIs for more than 5 years after deprecation. 
>> But to be clear, most of that time it's only security support for those 
>> APIs, and the APIs are long gone from master. Right?
>>
>> Thanks,
>> Collin
>>
>>
>> On Wednesday, June 10, 2015 at 1:37:30 PM UTC-4, Collin Anderson wrote:
>>>
>>> Hi All,
>>>
>>> Here are some thoughts in reply to some of the comments in the 
>>> django-compat thread. I don't stick to the LTSs myself, but I've helped 
>>> maintain apps that have 1.4 compatibility.
>>>
>>> On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:

 1.8 (LTS): No features dropped. 
 1.9: Dropped features deprecated in 1.4, 1.5, 1.6, 1.7 
 2.0: No features dropped. 
 2.1 (LTS): No features dropped. 
 2.2: Dropped features deprecated in 1.8, 1.9, 2.0 

>>>
>>> I'd propose something slightly different, that's very close to our 
>>> current deprecation timeline:
>>> 1.8 (LTS): No features dropped.
>>> 1.9: Dropped features deprecated in 1.5, 1.6, 1.7
>>> 2.0: Dropped features deprecated in 1.8
>>> 2.1 (LTS): No features dropped. 
>>> 2.2: Dropped features deprecated in 1.9, 2.0
>>> 2.3: Dropped features deprecated in 2.1
>>>
>>> Seems to me features deprecated in an LTS are fair game to disappear in 
>>> the next LTS. This allows us to remove "dotted paths in reverse() and 
>>> url()" because that's deprecated in 1.8.
>>>
>>> If we can guarantee compatibility between LTSs, I think that would be a 
>>> huge win, at the cost of extending the removal of some deprecated features 
>>> by one release (8 months). 
>>>
>>> Collin
>>>
>>>

-- 
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/512e9895-7216-4e0d-95dc-8c506c6646dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Carl Meyer]

On 06/10/2015 11:54 AM, Collin Anderson wrote:
> On Friday, May 8, 2015 at 12:12:37 PM UTC-4, Carl Meyer wrote:
> 
> And there is a significant added maintenance cost to my proposal 
> compared to yours. Dropping deprecated APIs in the release after an LTS 
> means we still have to support those APIs for three more years
> (possibly 
> for four or five years after they were first deprecated). Dropping them 
> _in_ the LTS release shortens that window drastically.
> 
> 
> If we release every 8 months, that means we normally support deprecated
> features for 2 years. If we maintained LTS compatibility, then, yes,
> that would mean "supporting" the APIs for more than 5 years after
> deprecation. But to be clear, most of that time it's only security
> support for those APIs, and the APIs are long gone from master. Right?

Yes, that's correct. The longest a deprecated API would ever have to
remain in master, under my proposal, would be from one LTS (the one it
is first deprecated in) until immediately after the next LTS branches
off from master.

It's worth noting that I above framed "we still have to [security]
support those [deprecated] APIs for [X] more years" as a negative -
added maintenance cost. But we should remember that from the point of
view of a user of Django like the one who just posted in django-users,
who maintains large numbers of infrequently-updated Django sites, those
extra years of security support for deprecated APIs could feel like a
huge relief.

I'm not sure how often having a deprecated API still present in a
security-supported version would actually make a security fix more
difficult. Obviously it's only an issue at all if there's a security
problem in a closely-related area of the code. If there's a security
problem in the deprecated API itself, it could result in an extra
security release we wouldn't even have needed to make otherwise.

I do still think that allowing third-party apps to have a simple "we
support all supported Django versions" policy, without needing to
implement their own compatibility wrappers, and thus hopefully allowing
upgrading users to take a simpler "first update dependencies, then
update Django" approach to LTS->LTS updates (instead of "first update
dependencies part of the way, then update Django part of the way, then
update dependencies again, then update Django again"), are all
significant benefits to my/Loïc's proposal.

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/55788DB6.3010003%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: 1.9 release planning

[Tim Graham]

Collin, I'm not following your reasoning about why dropping features 
deprecated in one LTS (e.g. 1.8) in the next LTS (e.g. 2.1; I think you 
made a typo in your timeline putting it next to 2.0?) will make it possible 
to easily support both LTS releases? That's the purpose of Loic's proposal 
I believe.

For "maintenance costs" I am not worried about supported deprecated APIs in 
old releases, only how long they stay around in master as that could be a 
barrier to innovation.

On Wednesday, June 10, 2015 at 1:54:53 PM UTC-4, Collin Anderson wrote:
>
> On Friday, May 8, 2015 at 12:12:37 PM UTC-4, Carl Meyer wrote:
>>
>> And there is a significant added maintenance cost to my proposal 
>> compared to yours. Dropping deprecated APIs in the release after an LTS 
>> means we still have to support those APIs for three more years (possibly 
>> for four or five years after they were first deprecated). Dropping them 
>> _in_ the LTS release shortens that window drastically.
>
>
> If we release every 8 months, that means we normally support deprecated 
> features for 2 years. If we maintained LTS compatibility, then, yes, that 
> would mean "supporting" the APIs for more than 5 years after deprecation. 
> But to be clear, most of that time it's only security support for those 
> APIs, and the APIs are long gone from master. Right?
>
> Thanks,
> Collin
>
>
> On Wednesday, June 10, 2015 at 1:37:30 PM UTC-4, Collin Anderson wrote:
>>
>> Hi All,
>>
>> Here are some thoughts in reply to some of the comments in the 
>> django-compat thread. I don't stick to the LTSs myself, but I've helped 
>> maintain apps that have 1.4 compatibility.
>>
>> On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:
>>>
>>> 1.8 (LTS): No features dropped. 
>>> 1.9: Dropped features deprecated in 1.4, 1.5, 1.6, 1.7 
>>> 2.0: No features dropped. 
>>> 2.1 (LTS): No features dropped. 
>>> 2.2: Dropped features deprecated in 1.8, 1.9, 2.0 
>>>
>>
>> I'd propose something slightly different, that's very close to our 
>> current deprecation timeline:
>> 1.8 (LTS): No features dropped.
>> 1.9: Dropped features deprecated in 1.5, 1.6, 1.7
>> 2.0: Dropped features deprecated in 1.8
>> 2.1 (LTS): No features dropped. 
>> 2.2: Dropped features deprecated in 1.9, 2.0
>> 2.3: Dropped features deprecated in 2.1
>>
>> Seems to me features deprecated in an LTS are fair game to disappear in 
>> the next LTS. This allows us to remove "dotted paths in reverse() and 
>> url()" because that's deprecated in 1.8.
>>
>> If we can guarantee compatibility between LTSs, I think that would be a 
>> huge win, at the cost of extending the removal of some deprecated features 
>> by one release (8 months). 
>>
>> Collin
>>
>>

-- 
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/d1fa4a97-1662-4e8b-9cba-c047ba63e141%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Collin Anderson]

On Friday, May 8, 2015 at 12:12:37 PM UTC-4, Carl Meyer wrote:
>
> And there is a significant added maintenance cost to my proposal 
> compared to yours. Dropping deprecated APIs in the release after an LTS 
> means we still have to support those APIs for three more years (possibly 
> for four or five years after they were first deprecated). Dropping them 
> _in_ the LTS release shortens that window drastically.


If we release every 8 months, that means we normally support deprecated 
features for 2 years. If we maintained LTS compatibility, then, yes, that 
would mean "supporting" the APIs for more than 5 years after deprecation. 
But to be clear, most of that time it's only security support for those 
APIs, and the APIs are long gone from master. Right?

Thanks,
Collin


On Wednesday, June 10, 2015 at 1:37:30 PM UTC-4, Collin Anderson wrote:
>
> Hi All,
>
> Here are some thoughts in reply to some of the comments in the 
> django-compat thread. I don't stick to the LTSs myself, but I've helped 
> maintain apps that have 1.4 compatibility.
>
> On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:
>>
>> 1.8 (LTS): No features dropped. 
>> 1.9: Dropped features deprecated in 1.4, 1.5, 1.6, 1.7 
>> 2.0: No features dropped. 
>> 2.1 (LTS): No features dropped. 
>> 2.2: Dropped features deprecated in 1.8, 1.9, 2.0 
>>
>
> I'd propose something slightly different, that's very close to our current 
> deprecation timeline:
> 1.8 (LTS): No features dropped.
> 1.9: Dropped features deprecated in 1.5, 1.6, 1.7
> 2.0: Dropped features deprecated in 1.8
> 2.1 (LTS): No features dropped. 
> 2.2: Dropped features deprecated in 1.9, 2.0
> 2.3: Dropped features deprecated in 2.1
>
> Seems to me features deprecated in an LTS are fair game to disappear in 
> the next LTS. This allows us to remove "dotted paths in reverse() and 
> url()" because that's deprecated in 1.8.
>
> If we can guarantee compatibility between LTSs, I think that would be a 
> huge win, at the cost of extending the removal of some deprecated features 
> by one release (8 months). 
>
> Collin
>
>

-- 
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/d3fabc7e-6811-4a85-96c4-fdc651e366cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Collin Anderson]

Hi All,

Here are some thoughts in reply to some of the comments in the 
django-compat thread. I don't stick to the LTSs myself, but I've helped 
maintain apps that have 1.4 compatibility.

On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:
>
> 1.8 (LTS): No features dropped. 
> 1.9: Dropped features deprecated in 1.4, 1.5, 1.6, 1.7 
> 2.0: No features dropped. 
> 2.1 (LTS): No features dropped. 
> 2.2: Dropped features deprecated in 1.8, 1.9, 2.0 
>

I'd propose something slightly different, that's very close to our current 
deprecation timeline:
1.8 (LTS): No features dropped.
1.9: Dropped features deprecated in 1.5, 1.6, 1.7
2.0: Dropped features deprecated in 1.8
2.1 (LTS): No features dropped. 
2.2: Dropped features deprecated in 1.9, 2.0
2.3: Dropped features deprecated in 2.1

Seems to me features deprecated in an LTS are fair game to disappear in the 
next LTS. This allows us to remove "dotted paths in reverse() and url()" 
because that's deprecated in 1.8.

If we can guarantee compatibility between LTSs, I think that would be a 
huge win, at the cost of extending the removal of some deprecated features 
by one release (8 months). 

Collin

-- 
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/586e0962-f73f-40b5-9113-8a703f9afd68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Aymeric Augustin]

> On 8 juin 2015, at 15:25, Tim Graham  wrote:
> 
> Any other feedback on the proposal? I could assume no complaints is a good 
> sign, but some +1's would be easier to interpret. :-)

I think your proposal is a reasonable compromise. It came up briefly during 
some discussions among core devs at DjangoCon Europe and I don’t remember 
anyone suggesting an alternative.

-- 
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/AFF39905-ACC5-4D64-B928-7926D5F81DBD%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Asif Saifuddin]

+1 dude!! go for it!

On Mon, Jun 8, 2015 at 7:25 PM, Tim Graham  wrote:

> Any other feedback on the proposal? I could assume no complaints is a good
> sign, but some +1's would be easier to interpret. :-)
>
>
> On Monday, June 1, 2015 at 11:09:12 AM UTC-4, Collin Anderson wrote:
>>
>> I see. I missed the "first upgrade Django to the last release before the
>> next
>> LTS (e.g. upgrade 1.8->1.9->2.0), then upgrade your dependencies to the
>> newer version that supports both 2.0 and 2.1, and then finally upgrade
>> to 2.1." part.
>>
>> Thanks,
>> Collin
>>
>> On Monday, June 1, 2015 at 11:02:01 AM UTC-4, Tim Graham wrote:
>>>
>>> If we dropped 1.8 deprecated features in 2.0, then it would require
>>> libraries to add conditional code to support both the old and new ways of
>>> doing something. The idea is that a third-party app wouldn't need to make
>>> any updates (except those needed to accommodate for backwards incompatible
>>> changes) until the next LTS release.
>>>
>>> The idea is *not* to suggest apps should try to support two LTS
>>> releases. Making that easy on Django's end would require keeping deprecated
>>> features in Django significantly longer than this proposal. See Carl's post
>>> in the thread where we discussed the deprecation cycle changes:
>>> https://groups.google.com/d/msg/django-developers/qCjfOu-FPxQ/hccAcVChHMkJ
>>>
>>> On Monday, June 1, 2015 at 10:20:13 AM UTC-4, Collin Anderson wrote:

 1.8 - April 2015 (LTS): Dropped features deprecated in 1.6 [1.6 no
 longer supported].
 1.9 - Dec. 2015: Drop features deprecated in 1.7 [1.7 no longer
 supported].
 2.0 - Aug. 2016: No features dropped.
 2.1 - April 2017 (LTS): Drop features deprecated in 1.8, 1.9 [1.9 no
 longer supported, third party apps can update to support 2.0 as a minimum
 version; 1.8 users should use an old version of the third-party app for the
 ~1 year until 1.8 is unsupported].
 2.2 - Dec. 2017: Drop features deprecated in 2.0 [2.0 no longer
 supported].

 This is awesome.

 So why not to have 2.0 drop features features deprecated in 1.8? If the
 replacement pattern/feature is available in 1.8, the 3rd party app should
 be able to use the new feature to stay compatible, right? If anything I'd
 like to see us hold off on dropping features deprecated in 1.9 until after
 the LTS to help people migrate between LTSs.

 Thanks,
 Collin


 On Monday, June 1, 2015 at 9:20:07 AM UTC-4, Tim Graham wrote:
>
> I put together a draft proposal in the form of a potential
> djangoproject.com blog post. I've enabled commenting in case you have
> minor cosmetic comments, but please keep discussion about the content of
> the proposal itself on this mailing list. Also, please let me know of any
> additional questions or complaints that you'd like to see addressed in the
> last section.
>
> The overview is:
> * New major release every 8 months
> * New long-term support release every 2 years. LTS releases continue
> to be supported with security updates for 3 years.
> * Adjust the deprecation policy to make it easier for third-party apps
> to support all versions back to the last LTS.
>
>
> https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing
>
> On Tuesday, April 7, 2015 at 3:20:55 PM UTC-4, Collin Anderson wrote:
>>
>> On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:
>>>
>>> How about
>>>
>>> a 8 month release cycle and having a LTS in every two years and
>>> supporting the old LTS atleast 3 years from the release date? there 
>>> will be
>>> 3 version between two LTS.
>>>
>>
>> Interesting. I like the idea of having predictable release dates.
>>
>  --
> 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/MTvOPDNQXLI/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/d35a73d6-0974-403c-b1dd-dc12f3a8a21a%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 

Re: 1.9 release planning

[Tim Graham]

Any other feedback on the proposal? I could assume no complaints is a good 
sign, but some +1's would be easier to interpret. :-)

On Monday, June 1, 2015 at 11:09:12 AM UTC-4, Collin Anderson wrote:
>
> I see. I missed the "first upgrade Django to the last release before the 
> next 
> LTS (e.g. upgrade 1.8->1.9->2.0), then upgrade your dependencies to the 
> newer version that supports both 2.0 and 2.1, and then finally upgrade 
> to 2.1." part.
>
> Thanks,
> Collin
>
> On Monday, June 1, 2015 at 11:02:01 AM UTC-4, Tim Graham wrote:
>>
>> If we dropped 1.8 deprecated features in 2.0, then it would require 
>> libraries to add conditional code to support both the old and new ways of 
>> doing something. The idea is that a third-party app wouldn't need to make 
>> any updates (except those needed to accommodate for backwards incompatible 
>> changes) until the next LTS release.
>>
>> The idea is *not* to suggest apps should try to support two LTS releases. 
>> Making that easy on Django's end would require keeping deprecated features 
>> in Django significantly longer than this proposal. See Carl's post in the 
>> thread where we discussed the deprecation cycle changes: 
>> https://groups.google.com/d/msg/django-developers/qCjfOu-FPxQ/hccAcVChHMkJ
>>
>> On Monday, June 1, 2015 at 10:20:13 AM UTC-4, Collin Anderson wrote:
>>>
>>> 1.8 - April 2015 (LTS): Dropped features deprecated in 1.6 [1.6 no 
>>> longer supported].
>>> 1.9 - Dec. 2015: Drop features deprecated in 1.7 [1.7 no longer 
>>> supported].
>>> 2.0 - Aug. 2016: No features dropped.
>>> 2.1 - April 2017 (LTS): Drop features deprecated in 1.8, 1.9 [1.9 no 
>>> longer supported, third party apps can update to support 2.0 as a minimum 
>>> version; 1.8 users should use an old version of the third-party app for the 
>>> ~1 year until 1.8 is unsupported].
>>> 2.2 - Dec. 2017: Drop features deprecated in 2.0 [2.0 no longer 
>>> supported].
>>>
>>> This is awesome.
>>>
>>> So why not to have 2.0 drop features features deprecated in 1.8? If the 
>>> replacement pattern/feature is available in 1.8, the 3rd party app should 
>>> be able to use the new feature to stay compatible, right? If anything I'd 
>>> like to see us hold off on dropping features deprecated in 1.9 until after 
>>> the LTS to help people migrate between LTSs.
>>>
>>> Thanks,
>>> Collin
>>>
>>>
>>> On Monday, June 1, 2015 at 9:20:07 AM UTC-4, Tim Graham wrote:

 I put together a draft proposal in the form of a potential 
 djangoproject.com blog post. I've enabled commenting in case you have 
 minor cosmetic comments, but please keep discussion about the content of 
 the proposal itself on this mailing list. Also, please let me know of any 
 additional questions or complaints that you'd like to see addressed in the 
 last section.

 The overview is:
 * New major release every 8 months
 * New long-term support release every 2 years. LTS releases continue to 
 be supported with security updates for 3 years.
 * Adjust the deprecation policy to make it easier for third-party apps 
 to support all versions back to the last LTS.


 https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing

 On Tuesday, April 7, 2015 at 3:20:55 PM UTC-4, Collin Anderson wrote:
>
> On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:
>>
>> How about
>>
>> a 8 month release cycle and having a LTS in every two years and 
>> supporting the old LTS atleast 3 years from the release date? there will 
>> be 
>> 3 version between two LTS.
>>
>
> Interesting. I like the idea of having predictable release dates.
>


-- 
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/d35a73d6-0974-403c-b1dd-dc12f3a8a21a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Collin Anderson]

I see. I missed the "first upgrade Django to the last release before the 
next 
LTS (e.g. upgrade 1.8->1.9->2.0), then upgrade your dependencies to the 
newer version that supports both 2.0 and 2.1, and then finally upgrade 
to 2.1." part.

Thanks,
Collin

On Monday, June 1, 2015 at 11:02:01 AM UTC-4, Tim Graham wrote:
>
> If we dropped 1.8 deprecated features in 2.0, then it would require 
> libraries to add conditional code to support both the old and new ways of 
> doing something. The idea is that a third-party app wouldn't need to make 
> any updates (except those needed to accommodate for backwards incompatible 
> changes) until the next LTS release.
>
> The idea is *not* to suggest apps should try to support two LTS releases. 
> Making that easy on Django's end would require keeping deprecated features 
> in Django significantly longer than this proposal. See Carl's post in the 
> thread where we discussed the deprecation cycle changes: 
> https://groups.google.com/d/msg/django-developers/qCjfOu-FPxQ/hccAcVChHMkJ
>
> On Monday, June 1, 2015 at 10:20:13 AM UTC-4, Collin Anderson wrote:
>>
>> 1.8 - April 2015 (LTS): Dropped features deprecated in 1.6 [1.6 no longer 
>> supported].
>> 1.9 - Dec. 2015: Drop features deprecated in 1.7 [1.7 no longer 
>> supported].
>> 2.0 - Aug. 2016: No features dropped.
>> 2.1 - April 2017 (LTS): Drop features deprecated in 1.8, 1.9 [1.9 no 
>> longer supported, third party apps can update to support 2.0 as a minimum 
>> version; 1.8 users should use an old version of the third-party app for the 
>> ~1 year until 1.8 is unsupported].
>> 2.2 - Dec. 2017: Drop features deprecated in 2.0 [2.0 no longer 
>> supported].
>>
>> This is awesome.
>>
>> So why not to have 2.0 drop features features deprecated in 1.8? If the 
>> replacement pattern/feature is available in 1.8, the 3rd party app should 
>> be able to use the new feature to stay compatible, right? If anything I'd 
>> like to see us hold off on dropping features deprecated in 1.9 until after 
>> the LTS to help people migrate between LTSs.
>>
>> Thanks,
>> Collin
>>
>>
>> On Monday, June 1, 2015 at 9:20:07 AM UTC-4, Tim Graham wrote:
>>>
>>> I put together a draft proposal in the form of a potential 
>>> djangoproject.com blog post. I've enabled commenting in case you have 
>>> minor cosmetic comments, but please keep discussion about the content of 
>>> the proposal itself on this mailing list. Also, please let me know of any 
>>> additional questions or complaints that you'd like to see addressed in the 
>>> last section.
>>>
>>> The overview is:
>>> * New major release every 8 months
>>> * New long-term support release every 2 years. LTS releases continue to 
>>> be supported with security updates for 3 years.
>>> * Adjust the deprecation policy to make it easier for third-party apps 
>>> to support all versions back to the last LTS.
>>>
>>>
>>> https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing
>>>
>>> On Tuesday, April 7, 2015 at 3:20:55 PM UTC-4, Collin Anderson wrote:

 On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:
>
> How about
>
> a 8 month release cycle and having a LTS in every two years and 
> supporting the old LTS atleast 3 years from the release date? there will 
> be 
> 3 version between two LTS.
>

 Interesting. I like the idea of having predictable release dates.

>>>

-- 
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/2c2a867b-c9fd-4bb0-98fd-e2f740a76f9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Tim Graham]

If we dropped 1.8 deprecated features in 2.0, then it would require 
libraries to add conditional code to support both the old and new ways of 
doing something. The idea is that a third-party app wouldn't need to make 
any updates (except those needed to accommodate for backwards incompatible 
changes) until the next LTS release.

The idea is *not* to suggest apps should try to support two LTS releases. 
Making that easy on Django's end would require keeping deprecated features 
in Django significantly longer than this proposal. See Carl's post in the 
thread where we discussed the deprecation cycle changes: 
https://groups.google.com/d/msg/django-developers/qCjfOu-FPxQ/hccAcVChHMkJ

On Monday, June 1, 2015 at 10:20:13 AM UTC-4, Collin Anderson wrote:
>
> 1.8 - April 2015 (LTS): Dropped features deprecated in 1.6 [1.6 no longer 
> supported].
> 1.9 - Dec. 2015: Drop features deprecated in 1.7 [1.7 no longer supported].
> 2.0 - Aug. 2016: No features dropped.
> 2.1 - April 2017 (LTS): Drop features deprecated in 1.8, 1.9 [1.9 no 
> longer supported, third party apps can update to support 2.0 as a minimum 
> version; 1.8 users should use an old version of the third-party app for the 
> ~1 year until 1.8 is unsupported].
> 2.2 - Dec. 2017: Drop features deprecated in 2.0 [2.0 no longer supported].
>
> This is awesome.
>
> So why not to have 2.0 drop features features deprecated in 1.8? If the 
> replacement pattern/feature is available in 1.8, the 3rd party app should 
> be able to use the new feature to stay compatible, right? If anything I'd 
> like to see us hold off on dropping features deprecated in 1.9 until after 
> the LTS to help people migrate between LTSs.
>
> Thanks,
> Collin
>
>
> On Monday, June 1, 2015 at 9:20:07 AM UTC-4, Tim Graham wrote:
>>
>> I put together a draft proposal in the form of a potential 
>> djangoproject.com blog post. I've enabled commenting in case you have 
>> minor cosmetic comments, but please keep discussion about the content of 
>> the proposal itself on this mailing list. Also, please let me know of any 
>> additional questions or complaints that you'd like to see addressed in the 
>> last section.
>>
>> The overview is:
>> * New major release every 8 months
>> * New long-term support release every 2 years. LTS releases continue to 
>> be supported with security updates for 3 years.
>> * Adjust the deprecation policy to make it easier for third-party apps to 
>> support all versions back to the last LTS.
>>
>>
>> https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing
>>
>> On Tuesday, April 7, 2015 at 3:20:55 PM UTC-4, Collin Anderson wrote:
>>>
>>> On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:

 How about

 a 8 month release cycle and having a LTS in every two years and 
 supporting the old LTS atleast 3 years from the release date? there will 
 be 
 3 version between two LTS.

>>>
>>> Interesting. I like the idea of having predictable release dates.
>>>
>>

-- 
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/acf37866-7a8c-4077-a399-0627acddd885%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Collin Anderson]

1.8 - April 2015 (LTS): Dropped features deprecated in 1.6 [1.6 no longer 
supported].
1.9 - Dec. 2015: Drop features deprecated in 1.7 [1.7 no longer supported].
2.0 - Aug. 2016: No features dropped.
2.1 - April 2017 (LTS): Drop features deprecated in 1.8, 1.9 [1.9 no longer 
supported, third party apps can update to support 2.0 as a minimum version; 
1.8 users should use an old version of the third-party app for the ~1 year 
until 1.8 is unsupported].
2.2 - Dec. 2017: Drop features deprecated in 2.0 [2.0 no longer supported].

This is awesome.

So why not to have 2.0 drop features features deprecated in 1.8? If the 
replacement pattern/feature is available in 1.8, the 3rd party app should 
be able to use the new feature to stay compatible, right? If anything I'd 
like to see us hold off on dropping features deprecated in 1.9 until after 
the LTS to help people migrate between LTSs.

Thanks,
Collin


On Monday, June 1, 2015 at 9:20:07 AM UTC-4, Tim Graham wrote:
>
> I put together a draft proposal in the form of a potential 
> djangoproject.com blog post. I've enabled commenting in case you have 
> minor cosmetic comments, but please keep discussion about the content of 
> the proposal itself on this mailing list. Also, please let me know of any 
> additional questions or complaints that you'd like to see addressed in the 
> last section.
>
> The overview is:
> * New major release every 8 months
> * New long-term support release every 2 years. LTS releases continue to be 
> supported with security updates for 3 years.
> * Adjust the deprecation policy to make it easier for third-party apps to 
> support all versions back to the last LTS.
>
>
> https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing
>
> On Tuesday, April 7, 2015 at 3:20:55 PM UTC-4, Collin Anderson wrote:
>>
>> On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:
>>>
>>> How about
>>>
>>> a 8 month release cycle and having a LTS in every two years and 
>>> supporting the old LTS atleast 3 years from the release date? there will be 
>>> 3 version between two LTS.
>>>
>>
>> Interesting. I like the idea of having predictable release dates.
>>
>

-- 
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/74456b73-2405-4484-8182-6f880f998752%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Asif Saifuddin]

thats great!!!

On Mon, Jun 1, 2015 at 7:20 PM, Tim Graham  wrote:

> I put together a draft proposal in the form of a potential
> djangoproject.com blog post. I've enabled commenting in case you have
> minor cosmetic comments, but please keep discussion about the content of
> the proposal itself on this mailing list. Also, please let me know of any
> additional questions or complaints that you'd like to see addressed in the
> last section.
>
> The overview is:
> * New major release every 8 months
> * New long-term support release every 2 years. LTS releases continue to be
> supported with security updates for 3 years.
> * Adjust the deprecation policy to make it easier for third-party apps to
> support all versions back to the last LTS.
>
>
> https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing
>
> On Tuesday, April 7, 2015 at 3:20:55 PM UTC-4, Collin Anderson wrote:
>>
>> On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:
>>>
>>> How about
>>>
>>> a 8 month release cycle and having a LTS in every two years and
>>> supporting the old LTS atleast 3 years from the release date? there will be
>>> 3 version between two LTS.
>>>
>>
>> Interesting. I like the idea of having predictable release dates.
>>
>  --
> 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/MTvOPDNQXLI/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/5e38433f-f499-483c-88aa-0d2744fad9cb%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/CAKAqTgqNARxgzJ48W_tcY5Frk0Z01TzXJEjg6W3QtnCuAHkj4g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Tim Graham]

I put together a draft proposal in the form of a potential 
djangoproject.com blog post. I've enabled commenting in case you have minor 
cosmetic comments, but please keep discussion about the content of the 
proposal itself on this mailing list. Also, please let me know of any 
additional questions or complaints that you'd like to see addressed in the 
last section.

The overview is:
* New major release every 8 months
* New long-term support release every 2 years. LTS releases continue to be 
supported with security updates for 3 years.
* Adjust the deprecation policy to make it easier for third-party apps to 
support all versions back to the last LTS.

https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing

On Tuesday, April 7, 2015 at 3:20:55 PM UTC-4, Collin Anderson wrote:
>
> On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:
>>
>> How about
>>
>> a 8 month release cycle and having a LTS in every two years and 
>> supporting the old LTS atleast 3 years from the release date? there will be 
>> 3 version between two LTS.
>>
>
> Interesting. I like the idea of having predictable release dates.
>

-- 
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/5e38433f-f499-483c-88aa-0d2744fad9cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Collin Anderson]

On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:
>
> How about
>
> a 8 month release cycle and having a LTS in every two years and supporting 
> the old LTS atleast 3 years from the release date? there will be 3 version 
> between two LTS.
>

Interesting. I like the idea of having predictable release dates.

-- 
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/33609d33-edc9-4ec1-a324-cdcad74a51f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Asif Saifuddin]

How about

a 8 month release cycle and having a LTS in every two years and supporting 
the old LTS atleast 3 years from the release date? there will be 3 version 
between two LTS.

On Thursday, March 12, 2015 at 6:13:11 AM UTC+6, Tim Graham wrote:
>
> With the release of 1.8 coming up, it's time to think about 1.9! I've 
> suggested some dates below. The schedule is similar to the intervals we 
> used for 1.8 with the final release date planned for about 6 months after 
> 1.8 final (barring unforeseen delays, 1.8 will be released about 7 months 
> after 1.7). Please voice any thoughts or concerns. With this schedule it 
> seems that any GSoC work would likely be included in 2.0. If you have any 
> big features planned, please add them here: 
> https://code.djangoproject.com/wiki/Version1.9Roadmap
>
> July 20 - Alpha (feature freeze)
> August 21 - Beta (only release blockers fixed after this)
> September 18 - RC (string freeze for translations)
> October 2 - Final
>

-- 
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/eb57f50b-a07d-4e0f-80a6-7fb845d193d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Markus Holtermann]

On Tuesday, April 7, 2015 at 1:21:20 AM UTC+2, Tim Graham wrote:
>
> With a 9 month schedule, here is what the future might look like:
>
> 1.8 - April 2015
> 1.9 - January 2016
> 2.0 - October 2016
> 2.1 - July 2017 (LTS, and might be the last version to support Python 2.7 
> since 3 years of LTS support would cover until the 2020 sunset.)
> 2.2 - April 2018
>
> Do you think there would be any value in putting together a short survey 
> for the community to get a wider consensus?
>

I think the above schedule is a good trade-off between giving companies 
time for their bureaucracy and getting features out to users frequently 
(those who can't (as in "don't want to") wait to use the new features can 
always use the release branch and get involved in testing).

I like the idea of getting the community involved here. But what are we 
planning to say if the majority says "no, that's too often / not often 
enough"? Both, more frequent releases and less frequent releases as they 
happened in the past, have their pros and cons.
 
Markus

On Monday, April 6, 2015 at 5:30:40 PM UTC-4, Shai Berger wrote:
>>
>> On Monday 06 April 2015 23:34:09 Chris Foresman wrote: 
>> > I'm really curious to know if the version to follow 1.9 is planned to 
>> be 
>> > 2.0 or 1.10. I feel as though 1.x releases have had a lot of major 
>> feature 
>> > changes. Maybe it's time to start thinking about features in terms of 
>> > major, minor, and bugfix/security patch, and start saving major 
>> features 
>> > for a 2.0 release that could be LTS. In the meantime, minor features 
>> could 
>> > be added to 1.9, 1.10, 1.11, etc, and breaking API changes should be 
>> added 
>> > to 2.x, or 3.x, etc. This would make it (IMO) easier to evaluate 
>> upgrade 
>> > paths, while maintaining the six-month cadence for .x releases of minor 
>> > features. 
>> > 
>> This was decided a little before 1.7 was released: the version after 1.9 
>> will 
>> be called 2.0, but it is not going to break things more than earlier 
>> releases 
>> (there are already warning classes named RemovedInDjango20Warning and   
>> RemovedInDjango21Warning in the sources, anticipating the releases after 
>> 1.9). 
>>
>> Shai. 
>>
>

-- 
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/c151c546-dfe1-46f9-9f89-4bc8ee68b133%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Marc Tamlyn]

This looks like a good plan to me. The main reason for shortening it before
as far as I could tell was the lengthy alpha to final process, which hasn't
happened this time and hopefully will be rather less frequent in future.

Marc

On 7 April 2015 at 00:21, Tim Graham  wrote:

> With a 9 month schedule, here is what the future might look like:
>
> 1.8 - April 2015
> 1.9 - January 2016
> 2.0 - October 2016
> 2.1 - July 2017 (LTS, and might be the last version to support Python 2.7
> since 3 years of LTS support would cover until the 2020 sunset.)
> 2.2 - April 2018
>
> Do you think there would be any value in putting together a short survey
> for the community to get a wider consensus?
>
>
> On Monday, April 6, 2015 at 5:30:40 PM UTC-4, Shai Berger wrote:
>>
>> On Monday 06 April 2015 23:34:09 Chris Foresman wrote:
>> > I'm really curious to know if the version to follow 1.9 is planned to
>> be
>> > 2.0 or 1.10. I feel as though 1.x releases have had a lot of major
>> feature
>> > changes. Maybe it's time to start thinking about features in terms of
>> > major, minor, and bugfix/security patch, and start saving major
>> features
>> > for a 2.0 release that could be LTS. In the meantime, minor features
>> could
>> > be added to 1.9, 1.10, 1.11, etc, and breaking API changes should be
>> added
>> > to 2.x, or 3.x, etc. This would make it (IMO) easier to evaluate
>> upgrade
>> > paths, while maintaining the six-month cadence for .x releases of minor
>> > features.
>> >
>> This was decided a little before 1.7 was released: the version after 1.9
>> will
>> be called 2.0, but it is not going to break things more than earlier
>> releases
>> (there are already warning classes named RemovedInDjango20Warning and
>> RemovedInDjango21Warning in the sources, anticipating the releases after
>> 1.9).
>>
>> Shai.
>>
>  --
> 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/56675028-6c26-4f72-9491-98f2db0f529e%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/CAMwjO1FBi1f1wOYXAThzT0OfZt9JekO5g53jcy5uOtn%2B9uw58g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Tim Graham]

With a 9 month schedule, here is what the future might look like:

1.8 - April 2015
1.9 - January 2016
2.0 - October 2016
2.1 - July 2017 (LTS, and might be the last version to support Python 2.7 
since 3 years of LTS support would cover until the 2020 sunset.)
2.2 - April 2018

Do you think there would be any value in putting together a short survey 
for the community to get a wider consensus?

On Monday, April 6, 2015 at 5:30:40 PM UTC-4, Shai Berger wrote:
>
> On Monday 06 April 2015 23:34:09 Chris Foresman wrote: 
> > I'm really curious to know if the version to follow 1.9 is planned to be 
> > 2.0 or 1.10. I feel as though 1.x releases have had a lot of major 
> feature 
> > changes. Maybe it's time to start thinking about features in terms of 
> > major, minor, and bugfix/security patch, and start saving major features 
> > for a 2.0 release that could be LTS. In the meantime, minor features 
> could 
> > be added to 1.9, 1.10, 1.11, etc, and breaking API changes should be 
> added 
> > to 2.x, or 3.x, etc. This would make it (IMO) easier to evaluate upgrade 
> > paths, while maintaining the six-month cadence for .x releases of minor 
> > features. 
> > 
> This was decided a little before 1.7 was released: the version after 1.9 
> will 
> be called 2.0, but it is not going to break things more than earlier 
> releases 
> (there are already warning classes named RemovedInDjango20Warning and   
> RemovedInDjango21Warning in the sources, anticipating the releases after 
> 1.9). 
>
> Shai. 
>

-- 
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/56675028-6c26-4f72-9491-98f2db0f529e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Shai Berger]

On Monday 06 April 2015 23:34:09 Chris Foresman wrote:
> I'm really curious to know if the version to follow 1.9 is planned to be
> 2.0 or 1.10. I feel as though 1.x releases have had a lot of major feature
> changes. Maybe it's time to start thinking about features in terms of
> major, minor, and bugfix/security patch, and start saving major features
> for a 2.0 release that could be LTS. In the meantime, minor features could
> be added to 1.9, 1.10, 1.11, etc, and breaking API changes should be added
> to 2.x, or 3.x, etc. This would make it (IMO) easier to evaluate upgrade
> paths, while maintaining the six-month cadence for .x releases of minor
> features.
> 
This was decided a little before 1.7 was released: the version after 1.9 will 
be called 2.0, but it is not going to break things more than earlier releases
(there are already warning classes named RemovedInDjango20Warning and  
RemovedInDjango21Warning in the sources, anticipating the releases after 1.9).

Shai.

Re: 1.9 release planning

[Aymeric Augustin]

Hello,

With the current system of release branches, the release schedule doesn’t 
affect much the rhythm at which Django accrues changes. For a given community 
of contributors and team of committers, the amount of changes in a new release 
is roughly proportional to its development time.

(We could have a discussion about backwards-compatibility but I’ll save it for 
another day.)

However the release schedule affects Django’s backwards-compatibility 
guarantees. Given the two-releases deprecation system, backwards-incompatible 
changes that require end users to adapt their code can happen in two time the 
duration of the release cycle.

Now, upgrading a project means:
1. checking which dependencies already support the newer Django version
2. finding a solution for the other dependencies (contributing, forking, 
replacing, etc.)
3. reading the release notes and trying to figure out what changes are needed
4. upgrading and running tests, both automated and manual
5. fixing whatever problems the tests reveal

3. and 5. are proportional to the amount of backwards-incompatible changes or, 
given my assumptions, to the amount of time since the last upgrade. 1., 2. and 
4. are more ore less fixed costs. 

Upgrading a pluggable application is the same story with an extra complication. 
Most applications support multiple version of Django at once.

With the two-release deprecation cycles, in practice, it’s quite easy to 
support consecutive releases N and N + 1, especially since we silenced 
PendingDeprecationWarning. It’s usually possible to support N and N + 2 if you 
accept the loud DeprecationWarning. However supporting N and N + 3 can be very 
hard. If N + 1 introduces significant changes (e.g. app-loading), N doesn’t 
contain anything to help with the transition and N + 3 completes the 
deprecation cycle by removing the code that helped the transition.

That’s the situation maintainers of third-party apps find themselves in since 
we introduced LTS releases: until recently,  1.4, 1.6 and 1.7 were supported; 
now, 1.4, 1.7 and 1.8.

As a consequence, I think that releases have a fairly high cost for our users 
and an even higher cost for maintainers of Django's open-source ecosystem. Each 
release starts the cycle of users asking maintainers to support the newer 
Django version, but maintainers don’t like the idea of dropping the oldest 
version yet, and supporting everything with the same code is complicated…

That’s why I think that shorter release cycles will do more harm than good. I 
believe that 9 months is a reasonable compromise.

Historically we aimed for 9 months and did 12. Then we aimed for 6 and did 9. 
With the fellowship, we know that we can reach the goal we set. I still think 
that 9 months is the right goal.

If we wanted to make more frequent major releases, I think we would have to:

- either tighten our rules on backwards-compatibility, which would hurt the  
pace of progress;
- or keep three releases under security support, which I’m not looking forward 
to.

Neither of these options seem better than a 9 month release cycle.

-- 
Aymeric.



> On 4 avr. 2015, at 14:30, Tim Graham  wrote:
> 
> Now that Django 1.8 is released, I wanted to bump this thread for discussion 
> so we can hopefully ratify this schedule or modify it based on feedback. In 
> particular, I heard a concern that a six month release schedule may be too 
> often for the community. On the other hand, I think smaller releases would 
> make incremental upgrades easier.
> 
> One difficulty could be if third-party packages try to support every version 
> since the last LTS (this seemed to be common with 1.4). A 6 month release 
> schedule would mean 5 versions of Django until the next LTS, instead of 3 as 
> we had since 1.4, so more `if DJANGO_X_Y` conditionals. One idea is that 
> third-party packages could declare their own "LTS" versions (if needed) and 
> drop support for older versions more freely in future development.
> 
> On Wednesday, March 11, 2015 at 8:13:11 PM UTC-4, Tim Graham wrote:
> With the release of 1.8 coming up, it's time to think about 1.9! I've 
> suggested some dates below. The schedule is similar to the intervals we used 
> for 1.8 with the final release date planned for about 6 months after 1.8 
> final (barring unforeseen delays, 1.8 will be released about 7 months after 
> 1.7). Please voice any thoughts or concerns. With this schedule it seems that 
> any GSoC work would likely be included in 2.0. If you have any big features 
> planned, please add them here: 
> https://code.djangoproject.com/wiki/Version1.9Roadmap 
> 
> 
> July 20 - Alpha (feature freeze)
> August 21 - Beta (only release blockers fixed after this)
> September 18 - RC (string freeze for translations)
> October 2 - Final
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django 

Re: 1.9 release planning

[Chris Foresman]

I'm really curious to know if the version to follow 1.9 is planned to be 
2.0 or 1.10. I feel as though 1.x releases have had a lot of major feature 
changes. Maybe it's time to start thinking about features in terms of 
major, minor, and bugfix/security patch, and start saving major features 
for a 2.0 release that could be LTS. In the meantime, minor features could 
be added to 1.9, 1.10, 1.11, etc, and breaking API changes should be added 
to 2.x, or 3.x, etc. This would make it (IMO) easier to evaluate upgrade 
paths, while maintaining the six-month cadence for .x releases of minor 
features.

As it is, even for short projects we end up having to stay on whatever 
version of Django we started with because the client won't pay for the work 
required to upgrade. Then each version that gets released is yet more work 
that needs done, so the estimate to update gets larger and larger every six 
months. The net effect is we get stuck on older versions unable to take 
advantage of those new features anyhowways.



On Saturday, April 4, 2015 at 7:30:59 AM UTC-5, Tim Graham wrote:
>
> Now that Django 1.8 is released, I wanted to bump this thread for 
> discussion so we can hopefully ratify this schedule or modify it based on 
> feedback. In particular, I heard a concern that a six month release 
> schedule may be too often for the community. On the other hand, I think 
> smaller releases would make incremental upgrades easier.
>
> One difficulty could be if third-party packages try to support every 
> version since the last LTS (this seemed to be common with 1.4). A 6 month 
> release schedule would mean 5 versions of Django until the next LTS, 
> instead of 3 as we had since 1.4, so more `if DJANGO_X_Y` conditionals. One 
> idea is that third-party packages could declare their own "LTS" versions 
> (if needed) and drop support for older versions more freely in future 
> development.
>
> On Wednesday, March 11, 2015 at 8:13:11 PM UTC-4, Tim Graham wrote:
>>
>> With the release of 1.8 coming up, it's time to think about 1.9! I've 
>> suggested some dates below. The schedule is similar to the intervals we 
>> used for 1.8 with the final release date planned for about 6 months after 
>> 1.8 final (barring unforeseen delays, 1.8 will be released about 7 months 
>> after 1.7). Please voice any thoughts or concerns. With this schedule it 
>> seems that any GSoC work would likely be included in 2.0. If you have any 
>> big features planned, please add them here: 
>> https://code.djangoproject.com/wiki/Version1.9Roadmap
>>
>> July 20 - Alpha (feature freeze)
>> August 21 - Beta (only release blockers fixed after this)
>> September 18 - RC (string freeze for translations)
>> October 2 - Final
>>
>

-- 
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/9d472e86-2f2c-4e20-8c77-17b3be5e2a1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Carl Meyer]

Hi Tim,

On 04/04/2015 06:30 AM, Tim Graham wrote:
> Now that Django 1.8 is released, I wanted to bump this thread for
> discussion so we can hopefully ratify this schedule or modify it based
> on feedback. In particular, I heard a concern that a six month release
> schedule may be too often for the community. On the other hand, I think
> smaller releases would make incremental upgrades easier.

In practice I'm not sure that "smaller releases make incremental
upgrades easier" pans out consistently. Shai pointed out that in large
organizations the simple fact of an upgrade is often a bureaucratic
hurdle apart from technical considerations; I'd say even in more nimble
organizations, simply needing to set aside developer time for an upgrade
is a fixed cognitive cost that "weighs" (in user perception) at least as
much as the technical difficulty of performing the upgrade itself.

I also think there's a benefit in smaller releases and getting features
to users quicker. I'm not sure where the sweet spot is (or if there even
is one).

FWIW, (per http://railsapps.github.io/rails-release-history.html) Rails'
last five gaps were 12 months (3.0 to 3.1), 5 months (3.1 to 3.2), 17
months (3.2 to 4.0), 11 months (4.0 to 4.1), and 8 months (4.1 to 4.2).
Not a lot of consistency there, but six months seems on the short end
for a comparable project.

Six month release cycles, plus a last-two-versions security-support
policy, implies that non-LTS users need to plan on at minimum yearly
upgrades (where they'd upgrade two versions at once). How much harder is
that than planning on releases every 18 months? It seems to me that if
either one of those is problematic for your organization, that means you
should be sticking with LTS releases; that's what they're for, after all.

(This may go without saying, but if we feel that asking people to
upgrade yearly is too much, I think it's much better to lengthen the
release cycle than to try to add security support for one more non-LTS
version. Security releases are hard enough to get out the door as-is.)

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/5522D303.6060700%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: 1.9 release planning

[Cheng Chi]

If 5 versions between LTS are too many, what about change LTS interval to 2 
years instead 3 years, like Ubuntu, so there are only 3 versions between 
two LTS versions.

Benefits:

- Easier to stick with one LTS instead of catching edge as you are only 1 
or 2 versions behind in most time. (If you start a new project just before 
a new LTS, building against cutting edge so you're on new LTS when your new 
project is ready!)
- Each LTS could still be supported for 3 years, the old LTS version will 
be supported for 1 more year after next LTS released, users and plugin 
authors have more time to upgrade their codes. (1 year vs 6 months)
- Easier to upgrade to new LTS version since less changes introduced 
between two LTS versions.
- Maximum waiting time for new features go into one LTS version is 18 
months instead 30 months.


On Saturday, April 4, 2015 at 11:30:59 PM UTC+11, Tim Graham wrote:
>
> Now that Django 1.8 is released, I wanted to bump this thread for 
> discussion so we can hopefully ratify this schedule or modify it based on 
> feedback. In particular, I heard a concern that a six month release 
> schedule may be too often for the community. On the other hand, I think 
> smaller releases would make incremental upgrades easier.
>
> One difficulty could be if third-party packages try to support every 
> version since the last LTS (this seemed to be common with 1.4). A 6 month 
> release schedule would mean 5 versions of Django until the next LTS, 
> instead of 3 as we had since 1.4, so more `if DJANGO_X_Y` conditionals. One 
> idea is that third-party packages could declare their own "LTS" versions 
> (if needed) and drop support for older versions more freely in future 
> development.
>
> On Wednesday, March 11, 2015 at 8:13:11 PM UTC-4, Tim Graham wrote:
>>
>> With the release of 1.8 coming up, it's time to think about 1.9! I've 
>> suggested some dates below. The schedule is similar to the intervals we 
>> used for 1.8 with the final release date planned for about 6 months after 
>> 1.8 final (barring unforeseen delays, 1.8 will be released about 7 months 
>> after 1.7). Please voice any thoughts or concerns. With this schedule it 
>> seems that any GSoC work would likely be included in 2.0. If you have any 
>> big features planned, please add them here: 
>> https://code.djangoproject.com/wiki/Version1.9Roadmap
>>
>> July 20 - Alpha (feature freeze)
>> August 21 - Beta (only release blockers fixed after this)
>> September 18 - RC (string freeze for translations)
>> October 2 - Final
>>
>

-- 
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/db52498f-d7b4-4c31-a9e0-df246a6115a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Shai Berger]

On Saturday 04 April 2015 21:16:54 Michael Manfre wrote:
> On Sat, Apr 4, 2015 at 12:56 PM, Thomas Tanner  wrote:
> > I think rare LTS releases and frequent (6month) incremental upgrades are
> > a good compromise.
> > Third-party packages should support LTS releases and at least the latest
> > Django version. They may drop support for earlier non-LTS releases.
> > Either you stick with the LTS release or you go with the cutting edge
> > with all dependencies.
> 
> I'm not advocating for or against more frequent releases, but trying to
> impose a support policy upon 3rd party packages is not going to work. 

I agree fully.


> The number or frequency of releases doesn't matter as much as the content
> of the releases.

Here I disagree. For our more corporate-oriented users, version upgrades are a 
beaurocratic hassle as well as a technical one. But also on the technical 
level, each version upgrade has overhead in testing and validation; and 
sometimes, for full-project products just as much as for 3rd-party apps, the 
problems of supporting multiple versions at once.

The clients I've worked with were having a hard time keeping up as it was.

Shai.

Re: 1.9 release planning

[Michael Manfre]

On Sat, Apr 4, 2015 at 12:56 PM, Thomas Tanner  wrote:

> I think rare LTS releases and frequent (6month) incremental upgrades are
> a good compromise.
> Third-party packages should support LTS releases and at least the latest
> Django version. They may drop support for earlier non-LTS releases.
> Either you stick with the LTS release or you go with the cutting edge
> with all dependencies.
>

I'm not advocating for or against more frequent releases, but trying to
impose a support policy upon 3rd party packages is not going to work. It
would great if they support whatever versions of Django are still
supported, but sometimes that takes more time/effort than the maintainer is
willing to devote.

The number or frequency of releases doesn't matter as much as the content
of the releases. Depending on the app, some Django versions are harder to
support at the same time. The back-to-back major changes to the Datatbase
API forced django-mssql to only support a single Django version with each
release. After that change, I was less inclined to backport fixes and even
stopped testing against Django 1.4 well before it was out of support.



> Advantages of release early, release often are that new features have
> more time to mature before a LTS release, you don't have to risk using
> the unstable HEAD for new features, and more feedback from users.
>
> On 04.04.15 14:30, Tim Graham wrote:
> > Now that Django 1.8 is released, I wanted to bump this thread for
> > discussion so we can hopefully ratify this schedule or modify it based
> > on feedback. In particular, I heard a concern that a six month release
> > schedule may be too often for the community. On the other hand, I think
> > smaller releases would make incremental upgrades easier.
> >
> > One difficulty could be if third-party packages try to support every
> > version since the last LTS (this seemed to be common with 1.4). A 6
> > month release schedule would mean 5 versions of Django until the next
> > LTS, instead of 3 as we had since 1.4, so more `if DJANGO_X_Y`
> > conditionals. One idea is that third-party packages could declare their
> > own "LTS" versions (if needed) and drop support for older versions more
> > freely in future development.
>
> --
> 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/552017D7.6020907%40gmx.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/CAGdCwBvxx%3DVKUscGQV1v%3DezeRkJVY4VJzDBZd9OaJ5SF9951oA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Thomas Tanner]

I think rare LTS releases and frequent (6month) incremental upgrades are
a good compromise.
Third-party packages should support LTS releases and at least the latest
Django version. They may drop support for earlier non-LTS releases.
Either you stick with the LTS release or you go with the cutting edge
with all dependencies.

Advantages of release early, release often are that new features have
more time to mature before a LTS release, you don't have to risk using
the unstable HEAD for new features, and more feedback from users.

On 04.04.15 14:30, Tim Graham wrote:
> Now that Django 1.8 is released, I wanted to bump this thread for
> discussion so we can hopefully ratify this schedule or modify it based
> on feedback. In particular, I heard a concern that a six month release
> schedule may be too often for the community. On the other hand, I think
> smaller releases would make incremental upgrades easier.
> 
> One difficulty could be if third-party packages try to support every
> version since the last LTS (this seemed to be common with 1.4). A 6
> month release schedule would mean 5 versions of Django until the next
> LTS, instead of 3 as we had since 1.4, so more `if DJANGO_X_Y`
> conditionals. One idea is that third-party packages could declare their
> own "LTS" versions (if needed) and drop support for older versions more
> freely in future development.

-- 
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/552017D7.6020907%40gmx.net.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Thorsten Sanders]

Am 04.04.2015 14:30, schrieb Tim Graham:
Now that Django 1.8 is released, I wanted to bump this thread for 
discussion so we can hopefully ratify this schedule or modify it based 
on feedback. In particular, I heard a concern that a six month release 
schedule may be too often for the community. On the other hand, I 
think smaller releases would make incremental upgrades easier.
I started to use django years ago and I like it but these fast releases 
result in quite some projects running django version not getting any 
security fixes anymore, yes there is the LTS but if I start a new 
project I use the current version to get features not being in the LTS 
version and I dont have the time to upgrade all projects to the current 
and do in depth testing if all works like expected and such a fast 
release cycle makes it even worse, if there is such an fast release 
cycle at least older version should get security fixes too otherwise its 
kinda unattractive to use it.




One difficulty could be if third-party packages try to support every 
version since the last LTS (this seemed to be common with 1.4). A 6 
month release schedule would mean 5 versions of Django until the next 
LTS, instead of 3 as we had since 1.4, so more `if DJANGO_X_Y` 
conditionals. One idea is that third-party packages could declare 
their own "LTS" versions (if needed) and drop support for older 
versions more freely in future development.


On Wednesday, March 11, 2015 at 8:13:11 PM UTC-4, Tim Graham wrote:

With the release of 1.8 coming up, it's time to think about 1.9!
I've suggested some dates below. The schedule is similar to the
intervals we used for 1.8 with the final release date planned for
about 6 months after 1.8 final (barring unforeseen delays, 1.8
will be released about 7 months after 1.7). Please voice any
thoughts or concerns. With this schedule it seems that any GSoC
work would likely be included in 2.0. If you have any big features
planned, please add them here:
https://code.djangoproject.com/wiki/Version1.9Roadmap


July 20 - Alpha (feature freeze)
August 21 - Beta (only release blockers fixed after this)
September 18 - RC (string freeze for translations)
October 2 - Final

--
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/0df00068-112f-4e98-9201-78d6ba9ef97c%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/551FDF14.2080908%40gmx.net.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Tim Graham]

Now that Django 1.8 is released, I wanted to bump this thread for 
discussion so we can hopefully ratify this schedule or modify it based on 
feedback. In particular, I heard a concern that a six month release 
schedule may be too often for the community. On the other hand, I think 
smaller releases would make incremental upgrades easier.

One difficulty could be if third-party packages try to support every 
version since the last LTS (this seemed to be common with 1.4). A 6 month 
release schedule would mean 5 versions of Django until the next LTS, 
instead of 3 as we had since 1.4, so more `if DJANGO_X_Y` conditionals. One 
idea is that third-party packages could declare their own "LTS" versions 
(if needed) and drop support for older versions more freely in future 
development.

On Wednesday, March 11, 2015 at 8:13:11 PM UTC-4, Tim Graham wrote:
>
> With the release of 1.8 coming up, it's time to think about 1.9! I've 
> suggested some dates below. The schedule is similar to the intervals we 
> used for 1.8 with the final release date planned for about 6 months after 
> 1.8 final (barring unforeseen delays, 1.8 will be released about 7 months 
> after 1.7). Please voice any thoughts or concerns. With this schedule it 
> seems that any GSoC work would likely be included in 2.0. If you have any 
> big features planned, please add them here: 
> https://code.djangoproject.com/wiki/Version1.9Roadmap
>
> July 20 - Alpha (feature freeze)
> August 21 - Beta (only release blockers fixed after this)
> September 18 - RC (string freeze for translations)
> October 2 - Final
>

-- 
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/0df00068-112f-4e98-9201-78d6ba9ef97c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

1.9 release planning

[Tim Graham]

With the release of 1.8 coming up, it's time to think about 1.9! I've 
suggested some dates below. The schedule is similar to the intervals we 
used for 1.8 with the final release date planned for about 6 months after 
1.8 final (barring unforeseen delays, 1.8 will be released about 7 months 
after 1.7). Please voice any thoughts or concerns. With this schedule it 
seems that any GSoC work would likely be included in 2.0. If you have any 
big features planned, please add them here: 
https://code.djangoproject.com/wiki/Version1.9Roadmap

July 20 - Alpha (feature freeze)
August 21 - Beta (only release blockers fixed after this)
September 18 - RC (string freeze for translations)
October 2 - Final

-- 
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/7a64c11e-73f7-43ea-91df-32b149a46c00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.