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

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

Post by 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
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

[Thorsten Sanders]

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

Post by Tim Graham
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.
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
https://code.djangoproject.com/wiki/Version1.9Roadmap
<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
To post to this group, send email to
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
<https://groups.google.com/d/msgid/django-developers/0df00068-112f-4e98-9201-78d6ba9ef97c%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.

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

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

[Michael Manfre]

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

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.

Post by Thomas Tanner
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.

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

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

[Shai Berger]

Post by Michael Manfre

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

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.

Post by Michael Manfre
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.

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

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

Post by 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
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

[Carl Meyer]

Hi Tim,

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

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

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

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

Post by 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
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

[Shai Berger]

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

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.

[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?

Post by Tim Graham

Post by 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

Post by Chris Foresman
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

Post by Chris Foresman
be added to 1.9, 1.10, 1.11, etc, and breaking API changes should be

added

Post by Chris Foresman
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.

[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

Post by Tim Graham
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?

Post by Tim Graham

Post by Chris Foresman
I'm really curious to know if the version to follow 1.9 is planned to

be

Post by Chris Foresman
2.0 or 1.10. I feel as though 1.x releases have had a lot of major

feature

Post by Chris Foresman
changes. Maybe it's time to start thinking about features in terms of
major, minor, and bugfix/security patch, and start saving major

features

Post by Chris Foresman
for a 2.0 release that could be LTS. In the meantime, minor features

could

Post by Chris Foresman
be added to 1.9, 1.10, 1.11, etc, and breaking API changes should be

added

Post by Chris Foresman
to 2.x, or 3.x, etc. This would make it (IMO) easier to evaluate

upgrade

Post by Chris Foresman
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
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
<https://groups.google.com/d/msgid/django-developers/56675028-6c26-4f72-9491-98f2db0f529e%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Markus Holtermann]

Post by Tim Graham
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

Post by Tim Graham

Post by Tim Graham

Post by Chris Foresman
I'm really curious to know if the version to follow 1.9 is planned to

be

Post by Chris Foresman
2.0 or 1.10. I feel as though 1.x releases have had a lot of major

feature

Post by Chris Foresman
changes. Maybe it's time to start thinking about features in terms of
major, minor, and bugfix/security patch, and start saving major

features

Post by Chris Foresman
for a 2.0 release that could be LTS. In the meantime, minor features

could

Post by Chris Foresman
be added to 1.9, 1.10, 1.11, etc, and breaking API changes should be

added

Post by Chris Foresman
to 2.x, or 3.x, etc. This would make it (IMO) easier to evaluate

upgrade

Post by Chris Foresman
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.

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

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.
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 <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.
Visit this group at http://groups.google.com/group/django-developers <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 <https://groups.google.com/d/msgid/django-developers/0df00068-112f-4e98-9201-78d6ba9ef97c%40googlegroups.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

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

Post by 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
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

[Collin Anderson]

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

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

[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

Post by Collin Anderson

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

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

[Asif Saifuddin]

thats great!!!

Post by 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.
* 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

Post by Collin Anderson

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

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
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
<https://groups.google.com/d/msgid/django-developers/5e38433f-f499-483c-88aa-0d2744fad9cb%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[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

Post by 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.
* 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

Post by Collin Anderson

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

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

[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

Post by 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

Post by 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.
* 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

Post by Collin Anderson

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

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

[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

Post by 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
https://groups.google.com/d/msg/django-developers/qCjfOu-FPxQ/hccAcVChHMkJ

Post by 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

Post by 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.
* 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

Post by Collin Anderson

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

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

[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. :-)

Post by 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

Post by 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
https://groups.google.com/d/msg/django-developers/qCjfOu-FPxQ/hccAcVChHMkJ

Post by 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

Post by 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.
* 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

Post by Collin Anderson

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

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

[Asif Saifuddin]

+1 dude!! go for it!

Post by 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. :-)

Post by 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

Post by 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
https://groups.google.com/d/msg/django-developers/qCjfOu-FPxQ/hccAcVChHMkJ

Post by 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

Post by 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.
* 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

Post by Collin Anderson

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

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
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
<https://groups.google.com/d/msgid/django-developers/d35a73d6-0974-403c-b1dd-dc12f3a8a21a%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

[Aymeric Augustin]

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.

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

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

[Collin Anderson]

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

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.

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

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

Post by Collin Anderson

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

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.

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

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

Post by Tim Graham
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

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

Post by Collin Anderson

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

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.

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

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

Post by Carl Meyer
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.

Post by Tim Graham
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

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

Post by Collin Anderson

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

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.

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

[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

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

Post by Carl Meyer
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.

Post by Tim Graham
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

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

Post by Collin Anderson

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

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.

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

[Michael Manfre]

I like Colin's proposed schedule.

Regards,
Michael Manfre

Post by 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

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

Post by Tim Graham

Post by Carl Meyer
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

Post by Tim Graham

Post by Carl Meyer
the normal release schedule. Right? Because apps wouldn't need to use

those

Post by Tim Graham

Post by Carl Meyer
deprecated features to support both 1.8 and 2.1. We could drop them in

2.0

Post by Tim Graham

Post by Carl Meyer
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.

Post by Tim Graham
For "maintenance costs" I am not worried about supported deprecated

APIs

Post by Tim Graham

Post by Carl Meyer

Post by Tim Graham
in old releases, only how long they stay around in master as that

could be a

Post by Tim Graham

Post by Carl Meyer

Post by Tim Graham
barrier to innovation.

Right, so the cost would be an extra 8 months before removing features
deprecated in 1.9 from master.
Thanks,
Collin

Post by 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

Post by Tim Graham

Post by Carl Meyer

Post by Tim Graham
a typo in your timeline putting it next to 2.0?) will make it possible

to

Post by Tim Graham

Post by Carl Meyer

Post by Tim Graham
easily support both LTS releases? That's the purpose of Loic's

proposal I

Post by Tim Graham

Post by Carl Meyer

Post by Tim Graham
believe.
For "maintenance costs" I am not worried about supported deprecated

APIs

Post by Tim Graham

Post by Carl Meyer

Post by Tim Graham
in old releases, only how long they stay around in master as that

could be a

Post by Tim Graham

Post by Carl Meyer

Post by Tim Graham
barrier to innovation.

Post by Collin Anderson

And there is a significant added maintenance cost to my proposal
compared to yours. Dropping deprecated APIs in the release after an

LTS

Post by Tim Graham

Post by Carl Meyer

Post by Tim Graham

Post by Collin Anderson

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

Post by Tim Graham

Post by Carl Meyer

Post by Tim Graham

Post by Collin Anderson

_in_ the LTS release shortens that window drastically.

If we release every 8 months, that means we normally support

deprecated

Post by Tim Graham

Post by Carl Meyer

Post by Tim Graham

Post by Collin Anderson
features for 2 years. If we maintained LTS compatibility, then, yes,

that

Post by Tim Graham

Post by Carl Meyer

Post by Tim Graham

Post by Collin Anderson
would mean "supporting" the APIs for more than 5 years after

deprecation.

Post by Tim Graham

Post by Carl Meyer

Post by Tim Graham

Post by Collin Anderson
But to be clear, most of that time it's only security support for

those

Post by Tim Graham

Post by Carl Meyer

Post by Tim Graham

Post by Collin Anderson
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

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

Post by Tim Graham

Post by Carl Meyer

Post by Tim Graham

Post by Collin Anderson

maintain apps that have 1.4 compatibility.

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

Post by Tim Graham

Post by Carl Meyer

Post by Tim Graham

Post by Collin Anderson

the next LTS. This allows us to remove "dotted paths in reverse()

and url()"

Post by Tim Graham

Post by Carl Meyer

Post by Tim Graham

Post by Collin Anderson

because that's deprecated in 1.8.
If we can guarantee compatibility between LTSs, I think that would

be a

Post by Tim Graham

Post by Carl Meyer

Post by Tim Graham

Post by Collin Anderson

huge win, at the cost of extending the removal of some deprecated

features

Post by Tim Graham

Post by Carl Meyer

Post by Tim Graham

Post by Collin Anderson

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

Post by Tim Graham
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
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/CALMtK1EPNXZvV_ifgY1hOGFwSM7MFk%2BihRJWSMaQQ76VV23dcA%40mail.gmail.com
.
For more options, visit https://groups.google.com/d/optout.

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

[Carl Meyer]

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

[Matt Austin]

Post by Collin Anderson
I'd propose something slightly different, that's very close to our current
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

[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

Post by Thorsten Sanders

Post by Collin Anderson
I'd propose something slightly different, that's very close to our

current

Post by Collin Anderson
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

Post by Collin Anderson
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

Post by Collin Anderson
win, at the cost of extending the removal of some deprecated features by

one

Post by Collin Anderson
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

[Carl Meyer]

Hi Matt,

Post by Matt Austin

Post by Collin Anderson
I'd propose something slightly different, that's very close to our current
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

[Aymeric Augustin]

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.

[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

[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

Post by 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
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

[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

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

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

Post by 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

Post by 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

Post by Tim Graham
An alternative would be for the LTS to be the second-to-last minor

release before a major version bump.

Post by Tim Graham
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.

Post by Tim Graham
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.

Post by Tim Graham
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.

Post by Tim Graham
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

Post by Tim Graham
2.2 - 0 mos - (LTS) No features dropped
3.0 - 8 mos - All deprecations, including the LTS deprecations, are

removed

Post by Tim Graham
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

Post by Tim Graham
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.

Post by Tim Graham
Ryan
--
You received this message because you are subscribed to the Google

Groups "Django developers (Contributions to Django itself)" group.

Post by Tim Graham
To unsubscribe from this group and stop receiving emails from it, send

<javascript:>.

Post by Tim Graham
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.

Post by Tim Graham
For more options, visit https://groups.google.com/d/optout.

[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

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

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
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.
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.
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.
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/fc7744d0-20ed-43f0-8cfa-860494b32a0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Post by Loïc Bistuer
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

Post by 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).

Post by Tim Graham
I think Collin's proposal can match semver without additional overhead

when LTS are the final minor releases of any given major branch.

Post by Tim Graham
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.

Post by Tim Graham
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".

Post by Tim Graham
--
Loïc

Post by 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

Post by Tim Graham

Post by Tim Graham
An alternative would be for the LTS to be the second-to-last minor

release before a major version bump.

Post by Tim Graham

Post by Tim Graham
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.

Post by Tim Graham

Post by Tim Graham
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.

Post by Tim Graham

Post by Tim Graham
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.

Post by Tim Graham

Post by Tim Graham
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

Post by Tim Graham

Post by Tim Graham
2.2 - 0 mos - (LTS) No features dropped
3.0 - 8 mos - All deprecations, including the LTS deprecations, are

removed

Post by Tim Graham

Post by Tim Graham
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

Post by Tim Graham

Post by Tim Graham
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.

Post by Tim Graham

Post by Tim Graham
Ryan
--
You received this message because you are subscribed to the Google

Groups "Django developers (Contributions to Django itself)" group.

Post by Tim Graham

Post by Tim Graham
To unsubscribe from this group and stop receiving emails from it, send
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.

Post by Tim Graham

Post by Tim Graham
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.

Post by Tim Graham
To unsubscribe from this group and stop receiving emails from it, send

<javascript:>.

Post by Tim Graham
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/fc7744d0-20ed-43f0-8cfa-860494b32a0c%40googlegroups.com.

Post by Tim Graham
For more options, visit https://groups.google.com/d/optout.

[Loïc Bistuer]

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

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

Post by 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.
RemovedInDjango19Warning(DeprecationWarning) - Deprecations from 1.7
RemovedInDjango20Warning(PendingDeprecationWarning) - Deprecations from 1.8
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

[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 :)

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.

Post by 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.
RemovedInDjango19Warning(DeprecationWarning) - Deprecations from 1.7
RemovedInDjango20Warning(PendingDeprecationWarning) - Deprecations from 1.8
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

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

Post by Ryan Hiebert
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 :)
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.

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.

RemovedInDjango19Warning(DeprecationWarning) - Deprecations from 1.7
RemovedInDjango20Warning(PendingDeprecationWarning) - Deprecations from 1.8
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.
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.

[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

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

Post by Ryan Hiebert
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 :)
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.

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.

RemovedInDjango19Warning(DeprecationWarning) - Deprecations from 1.7
RemovedInDjango20Warning(PendingDeprecationWarning) - Deprecations from 1.8
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.
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.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
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/8FD2862C-D50D-44B9-8517-8C37417BF8BB%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Aymeric Augustin]

Post by 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

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.

[Tim Graham]

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

Post by Loïc Bistuer

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

[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

Post by Aymeric Augustin
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 :-)

[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

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

Post by Aymeric Augustin
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.
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.

[Carl Meyer]

Thanks Loïc,

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

[snip]

Post by Loïc Bistuer
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

Post by Loïc Bistuer
- 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

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

Post by Carl Meyer
Thanks Loïc,

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

[snip]

Post by Loïc Bistuer
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

Post by Loïc Bistuer
- 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

[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

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

Post by Carl Meyer
Thanks Loïc,

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

[snip]

Post by Loïc Bistuer
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

Post by Loïc Bistuer
- 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
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
<https://groups.google.com/d/msgid/django-developers/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

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

[Josh Smeaton]

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

Post by 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

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

Post by Carl Meyer
Thanks Loïc,

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

[snip]

Post by Loïc Bistuer
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

Post by Loïc Bistuer
- 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
<javascript:>.
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
<https://groups.google.com/d/msgid/django-developers/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

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

[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

I'm also +1 on the proposal as it stands, and neutral on when the semver versioning should begin.
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
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.
Thanks Loïc,

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

[snip]

Post by Loïc Bistuer
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

Post by Loïc Bistuer
- 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.
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.
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.

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

Post by 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

Post by Josh Smeaton
I'm also +1 on the proposal as it stands, and neutral on when the semver

versioning should begin.

Post by Josh Smeaton
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.

Post by Josh Smeaton
Regards,
Michael Manfre
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.

Post by Josh Smeaton
Thanks Loïc,

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

[snip]

Post by Loïc Bistuer
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

Post by Josh Smeaton
- Ryan's proposals

https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ

Post by Josh Smeaton

Post by Loïc Bistuer
- Loïc's proposal

https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ

Post by Josh Smeaton
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.

Post by Josh Smeaton
To unsubscribe from this group and stop receiving emails from it, send
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.

Post by Josh Smeaton
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.

Post by Josh Smeaton
To unsubscribe from this group and stop receiving emails from it, send

<javascript:>.

Post by Josh Smeaton
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.

Post by Josh Smeaton
For more options, visit https://groups.google.com/d/optout.

[Michael Manfre]

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

Post by 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

Post by Josh Smeaton
I'm also +1 on the proposal as it stands, and neutral on when the semver

versioning should begin.

Post by Josh Smeaton
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.

Post by Josh Smeaton
Regards,
Michael Manfre
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.

Post by Josh Smeaton
Thanks Loïc,

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

[snip]

Post by Loïc Bistuer
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

Post by Josh Smeaton
- Ryan's proposals

https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ

Post by Josh Smeaton

Post by Loïc Bistuer
- Loïc's proposal

https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ

Post by Josh Smeaton
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.

Post by Josh Smeaton
To unsubscribe from this group and stop receiving emails from it, send
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
.

Post by Josh Smeaton
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.

Post by Josh Smeaton
To unsubscribe from this group and stop receiving emails from it, send
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
.

Post by Josh Smeaton
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
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/857E068D-347C-4C6A-8A1F-41569C3BC476%40gmail.com
.
For more options, visit https://groups.google.com/d/optout.

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

[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

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

Post by 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

Post by Josh Smeaton
I'm also +1 on the proposal as it stands, and neutral on when the semver

versioning should begin.

Post by Josh Smeaton
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.

Post by Josh Smeaton
Regards,
Michael Manfre
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.

Post by Josh Smeaton
Thanks Loïc,

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

[snip]

Post by Loïc Bistuer
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

Post by Josh Smeaton
- Ryan's proposals

https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ

Post by Josh Smeaton

Post by Loïc Bistuer
- Loïc's proposal

https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ

Post by Josh Smeaton
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.

Post by Josh Smeaton
To unsubscribe from this group and stop receiving emails from it, send
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
.

Post by Josh Smeaton
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.

Post by Josh Smeaton
To unsubscribe from this group and stop receiving emails from it, send
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
.

Post by Josh Smeaton
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
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/857E068D-347C-4C6A-8A1F-41569C3BC476%40gmail.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.
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/CAGdCwBu4CVmS3yGcmM9hW0-22Exfm5b72FVA2CQ_h9O_zTCrPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Collin Anderson]

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

Post by 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

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

<javascript:>>

Post by Michael Manfre

Post by Loïc Bistuer
Just when we thought we had a winner... I'd like to make a final

proposal.

Post by Michael Manfre

Post by Loïc Bistuer
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

Post by Michael Manfre

Post by Loïc Bistuer
it still requires renaming PendingDeprecationWarnings in 1.8, and both
warnings in 1.9.
What do you think?
--
Loïc

Post by Josh Smeaton
I'm also +1 on the proposal as it stands, and neutral on when the

semver

Post by Michael Manfre

Post by Loïc Bistuer
versioning should begin.

Post by Josh Smeaton
I'm +1 on the Google doc proposal and like Markus, I support

relabeling

Post by Michael Manfre

Post by Loïc Bistuer
1.9 to 2.0 to line the versions up with the new paradigm without the

X.1

Post by Michael Manfre

Post by Loïc Bistuer
LTS oddball.

Post by Josh Smeaton
Regards,
Michael Manfre
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

Post by Michael Manfre

Post by Loïc Bistuer
the version numbers.

Post by Josh Smeaton
Thanks Loïc,

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

[snip]

Post by Loïc Bistuer
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

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
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

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
- Ryan's proposals

https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
- Loïc's proposal

https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
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

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
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

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
intuitive sense for the _last_ minor release in a major series to be

LTS

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
rather than the first).
Carl
--
You received this message because you are subscribed to the Google

Groups "Django developers (Contributions to Django itself)" group.

Post by Josh Smeaton
To unsubscribe from this group and stop receiving emails from it,

send

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
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

Post by Michael Manfre

Post by Loïc Bistuer
.

Post by Josh Smeaton
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.

Post by Josh Smeaton
To unsubscribe from this group and stop receiving emails from it,

send
<javascript:>.

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
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

Post by Michael Manfre

Post by Loïc Bistuer
.

Post by Josh Smeaton
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google

Groups

Post by Michael Manfre

Post by Loïc Bistuer
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send

an
<javascript:>.

Post by Michael Manfre

Post by Loïc Bistuer
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/857E068D-347C-4C6A-8A1F-41569C3BC476%40gmail.com

Post by Michael Manfre

Post by Loïc Bistuer
.
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.

Post by Michael Manfre
To unsubscribe from this group and stop receiving emails from it, send an

<javascript:>.

Post by Michael Manfre
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/CAGdCwBu4CVmS3yGcmM9hW0-22Exfm5b72FVA2CQ_h9O_zTCrPQ%40mail.gmail.com.

Post by Michael Manfre
For more options, visit https://groups.google.com/d/optout.

--

[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

Post by Collin Anderson
People import the warning in order to silence them, right?
+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

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

Post by 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

Post by Josh Smeaton
I'm also +1 on the proposal as it stands, and neutral on when the semver

versioning should begin.

Post by Josh Smeaton
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.

Post by Josh Smeaton
Regards,
Michael Manfre
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.

Post by Josh Smeaton
Thanks Loïc,

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

[snip]

Post by Loïc Bistuer
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

Post by Josh Smeaton
- Ryan's proposals

https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ

Post by Josh Smeaton

Post by Loïc Bistuer
- Loïc's proposal

https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ

Post by Josh Smeaton
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.

Post by Josh Smeaton
To unsubscribe from this group and stop receiving emails from it, send
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
.

Post by Josh Smeaton
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.

Post by Josh Smeaton
To unsubscribe from this group and stop receiving emails from it, send
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
.

Post by Josh Smeaton
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
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/857E068D-347C-4C6A-8A1F-41569C3BC476%40gmail.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.
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/CAGdCwBu4CVmS3yGcmM9hW0-22Exfm5b72FVA2CQ_h9O_zTCrPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
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/405d98f0-af6a-45b9-8bed-35fc9f99b8ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tim Graham]

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

Post by 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

Post by Collin Anderson
People import the warning in order to silence them, right?
+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

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

Post by Loïc Bistuer
Just when we thought we had a winner... I'd like to make a final

proposal.

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
Instead of delaying adoption of SemVer to 3.0 we could do so in 2.0

by

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
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

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
it still requires renaming PendingDeprecationWarnings in 1.8, and

both

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
warnings in 1.9.
What do you think?
--
Loïc

Post by Josh Smeaton
I'm also +1 on the proposal as it stands, and neutral on when the

semver

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
versioning should begin.

Post by Josh Smeaton
I'm +1 on the Google doc proposal and like Markus, I support

relabeling

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
1.9 to 2.0 to line the versions up with the new paradigm without the

X.1

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
LTS oddball.

Post by Josh Smeaton
Regards,
Michael Manfre
On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson <
I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0,

3.1,

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and

we

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
sacrifice a little bit of strict semver, but it give some nice

meaning to

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
the version numbers.

Post by Josh Smeaton
Thanks Loïc,

Post by Loïc Bistuer
I've attempted to summarize the history of this thread. Note that

I

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
marked as +1 any generally positive feedback towards a given
proposal, please correct if you feel misrepresented.

[snip]

Post by Loïc Bistuer
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

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
Collin, Carl, Loïc, Tim, and Josh have expressed positive

feedback to

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
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

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
reflect my latest proposal, so including me that's 2 formal +1

for

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
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

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
- Ryan's proposals

https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
- Loïc's proposal

https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
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

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
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

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
intuitive sense for the _last_ minor release in a major series to

be LTS

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
rather than the first).
Carl
--
You received this message because you are subscribed to the Google

Groups "Django developers (Contributions to Django itself)" group.

Post by Josh Smeaton
To unsubscribe from this group and stop receiving emails from it,

send

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
Visit this group at

http://groups.google.com/group/django-developers.

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
To view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
.

Post by Josh Smeaton
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.

Post by Josh Smeaton
To unsubscribe from this group and stop receiving emails from it,

send

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
Visit this group at

http://groups.google.com/group/django-developers.

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
To view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/79aae5a5-58dd-4f05-a6dd-35685e06ebb5%40googlegroups.com

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
.

Post by Josh Smeaton
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google

Groups

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it,

send an

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
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/857E068D-347C-4C6A-8A1F-41569C3BC476%40gmail.com

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
.
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.

Post by Collin Anderson

Post by Michael Manfre
To unsubscribe from this group and stop receiving emails from it, send
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/CAGdCwBu4CVmS3yGcmM9hW0-22Exfm5b72FVA2CQ_h9O_zTCrPQ%40mail.gmail.com.

Post by Collin Anderson

Post by Michael Manfre
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.

Post by Collin Anderson
To unsubscribe from this group and stop receiving emails from it, send

<javascript:>.

Post by Collin Anderson
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/405d98f0-af6a-45b9-8bed-35fc9f99b8ea%40googlegroups.com.

Post by Collin Anderson
For more options, visit https://groups.google.com/d/optout.

[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

Post by Tim Graham
Done that in https://github.com/django/django/pull/4908

Post by 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

Post by Collin Anderson
People import the warning in order to silence them, right?
+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

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

Post by Loïc Bistuer
Just when we thought we had a winner... I'd like to make a final

proposal.

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
Instead of delaying adoption of SemVer to 3.0 we could do so in 2.0

by

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
introducing the 1.10 and 1.11LTS releases.
The upside is that the new policy applies right away and we avoid

the

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
oddball 2.0 and 2.1 releases.
It's much less invasive than the previous idea of renaming 1.9 to

2.0, but

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
it still requires renaming PendingDeprecationWarnings in 1.8, and

both

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
warnings in 1.9.
What do you think?
--
Loïc

Post by Josh Smeaton
I'm also +1 on the proposal as it stands, and neutral on when the

semver

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
versioning should begin.

Post by Josh Smeaton
I'm +1 on the Google doc proposal and like Markus, I support

relabeling

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
1.9 to 2.0 to line the versions up with the new paradigm without the

X.1

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
LTS oddball.

Post by Josh Smeaton
Regards,
Michael Manfre
On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson <
I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0,

3.1,

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and

we

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
sacrifice a little bit of strict semver, but it give some nice

meaning to

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
the version numbers.

Post by Josh Smeaton
Thanks Loïc,

Post by Loïc Bistuer
I've attempted to summarize the history of this thread. Note

that I

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
marked as +1 any generally positive feedback towards a given
proposal, please correct if you feel misrepresented.

[snip]

Post by Loïc Bistuer
5/ Switching to Semantic Versioning
Donald mentioned SemVer on IRC a few days ago. Since then

various

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
proposal were made to reconcile it with our release policy. So

far

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
Collin, Carl, Loïc, Tim, and Josh have expressed positive

feedback to

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
various proposals in that direction but I don't think we have

yet

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
reached consensus on a specific one. Tim updated the Google doc

to

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
reflect my latest proposal, so including me that's 2 formal +1

for

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
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

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
- Ryan's proposals

https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
- Loïc's proposal

https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
FWIW, I am also +1 on your proposal, as currently documented in

the

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
Google doc.
I was trying to come up with a proposal where LTS == major release

for

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
the sake of argument, since it seemed like that was intuitive to

at

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
least some people, but it's not worth the required lengthening of
deprecation paths. Your proposal is much better. (And it does make

some

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
intuitive sense for the _last_ minor release in a major series to

be LTS

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
rather than the first).
Carl
--
You received this message because you are subscribed to the Google

Groups "Django developers (Contributions to Django itself)" group.

Post by Josh Smeaton
To unsubscribe from this group and stop receiving emails from it,

send

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
Visit this group at

http://groups.google.com/group/django-developers.

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
To view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
.

Post by Josh Smeaton
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.

Post by Josh Smeaton
To unsubscribe from this group and stop receiving emails from it,

send

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
Visit this group at

http://groups.google.com/group/django-developers.

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
To view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/79aae5a5-58dd-4f05-a6dd-35685e06ebb5%40googlegroups.com

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
.

Post by Josh Smeaton
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google

Groups

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it,

send an

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
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/857E068D-347C-4C6A-8A1F-41569C3BC476%40gmail.com

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
.
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.

Post by Collin Anderson

Post by Michael Manfre
To unsubscribe from this group and stop receiving emails from it, send
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/CAGdCwBu4CVmS3yGcmM9hW0-22Exfm5b72FVA2CQ_h9O_zTCrPQ%40mail.gmail.com.

Post by Collin Anderson

Post by Michael Manfre
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.

Post by Collin Anderson
To unsubscribe from this group and stop receiving emails from it, send
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/405d98f0-af6a-45b9-8bed-35fc9f99b8ea%40googlegroups.com.

Post by Collin Anderson
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
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/62f18b57-59f8-4da0-91e2-a8d7c28fbd2a%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/62f18b57-59f8-4da0-91e2-a8d7c28fbd2a%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

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

Post by 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

Post by Tim Graham
Done that in https://github.com/django/django/pull/4908

Post by 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

Post by Collin Anderson
People import the warning in order to silence them, right?
+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

Post by Collin Anderson
a public API. I've never seen them in the wild.
/Markus

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

Post by Loïc Bistuer
Just when we thought we had a winner... I'd like to make a final

proposal.

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
Instead of delaying adoption of SemVer to 3.0 we could do so in 2.0

by

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
introducing the 1.10 and 1.11LTS releases.
The upside is that the new policy applies right away and we avoid

the

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
oddball 2.0 and 2.1 releases.
It's much less invasive than the previous idea of renaming 1.9 to

2.0, but

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
it still requires renaming PendingDeprecationWarnings in 1.8, and

both

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
warnings in 1.9.
What do you think?
--
Loïc

Post by Josh Smeaton
I'm also +1 on the proposal as it stands, and neutral on when the

semver

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
versioning should begin.

Post by Josh Smeaton
I'm +1 on the Google doc proposal and like Markus, I support

relabeling

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
1.9 to 2.0 to line the versions up with the new paradigm without

the X.1

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
LTS oddball.

Post by Josh Smeaton
Regards,
Michael Manfre
On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson <
I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0,

3.1,

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and

we

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
sacrifice a little bit of strict semver, but it give some nice

meaning to

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
the version numbers.

Post by Josh Smeaton
Thanks Loïc,

Post by Loïc Bistuer
I've attempted to summarize the history of this thread. Note

that I

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
marked as +1 any generally positive feedback towards a given
proposal, please correct if you feel misrepresented.

[snip]

Post by Loïc Bistuer
5/ Switching to Semantic Versioning
Donald mentioned SemVer on IRC a few days ago. Since then

various

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
proposal were made to reconcile it with our release policy. So

far

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
Collin, Carl, Loïc, Tim, and Josh have expressed positive

feedback to

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
various proposals in that direction but I don't think we have

yet

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
reached consensus on a specific one. Tim updated the Google doc

to

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
reflect my latest proposal, so including me that's 2 formal +1

for

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
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

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
- Ryan's proposals

https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton

Post by Loïc Bistuer
- Loïc's proposal

https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
FWIW, I am also +1 on your proposal, as currently documented in

the

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
Google doc.
I was trying to come up with a proposal where LTS == major

release for

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
the sake of argument, since it seemed like that was intuitive to

at

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
least some people, but it's not worth the required lengthening of
deprecation paths. Your proposal is much better. (And it does

make some

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
intuitive sense for the _last_ minor release in a major series to

be LTS

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
rather than the first).
Carl
--
You received this message because you are subscribed to the

Google

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
Groups "Django developers (Contributions to Django itself)" group.

Post by Josh Smeaton
To unsubscribe from this group and stop receiving emails from it,

send

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
Visit this group at

http://groups.google.com/group/django-developers.

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
To view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
.

Post by Josh Smeaton
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

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
Groups "Django developers (Contributions to Django itself)" group.

Post by Josh Smeaton
To unsubscribe from this group and stop receiving emails from it,

send

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
Visit this group at

http://groups.google.com/group/django-developers.

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer

Post by Josh Smeaton
To view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/79aae5a5-58dd-4f05-a6dd-35685e06ebb5%40googlegroups.com

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
.

Post by Josh Smeaton
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google

Groups

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it,

send an

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
Visit this group at

http://groups.google.com/group/django-developers.

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
To view this discussion on the web visit

https://groups.google.com/d/msgid/django-developers/857E068D-347C-4C6A-8A1F-41569C3BC476%40gmail.com

Post by Collin Anderson

Post by Michael Manfre

Post by Loïc Bistuer
.
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.

Post by Collin Anderson

Post by Michael Manfre
To unsubscribe from this group and stop receiving emails from it,
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/CAGdCwBu4CVmS3yGcmM9hW0-22Exfm5b72FVA2CQ_h9O_zTCrPQ%40mail.gmail.com.

Post by Collin Anderson

Post by Michael Manfre
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.

Post by Collin Anderson
To unsubscribe from this group and stop receiving emails from it, send
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/405d98f0-af6a-45b9-8bed-35fc9f99b8ea%40googlegroups.com.

Post by Collin Anderson
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
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/62f18b57-59f8-4da0-91e2-a8d7c28fbd2a%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/62f18b57-59f8-4da0-91e2-a8d7c28fbd2a%40googlegroups.com?utm_medium=email&utm_source=footer>
.
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
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/CAMwjO1GvAnMx3TtO36hxgQN9coOmEKGO%3DJKSrOSs%2BOgGb-8qKQ%40mail.gmail.com
<https://groups.google.com/d/msgid/django-developers/CAMwjO1GvAnMx3TtO36hxgQN9coOmEKGO%3DJKSrOSs%2BOgGb-8qKQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

--
Aymeric.

[Anssi Kääriäinen]

+1 to not changing already planned version numbers.

- Anssi

On Tue, Jun 23, 2015 at 1:24 PM, Aymeric Augustin

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

Post by 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

Post by Tim Graham
Done that in https://github.com/django/django/pull/4908

Post by 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

Post by Collin Anderson
People import the warning in order to silence them, right?
+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

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

Post by 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

Post by Josh Smeaton
I'm also +1 on the proposal as it stands, and neutral on when the
semver

versioning should begin.

Post by Josh Smeaton
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.

Post by Josh Smeaton
Regards,
Michael Manfre
On Tue, Jun 16, 2015 at 12:34 PM, 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.

Post by Josh Smeaton
Thanks Loïc,

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

[snip]

Post by Loïc Bistuer
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

Post by Josh Smeaton
- Ryan's proposals

https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ

Post by Josh Smeaton

Post by Loïc Bistuer
- Loïc's proposal

https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ

Post by Josh Smeaton
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.

Post by Josh Smeaton
To unsubscribe from this group and stop receiving emails from it, send
To post to this group, send email to
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
.

Post by Josh Smeaton
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.

Post by Josh Smeaton
To unsubscribe from this group and stop receiving emails from it, send
To post to this group, send email to
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
.

Post by Josh Smeaton
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
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/857E068D-347C-4C6A-8A1F-41569C3BC476%40gmail.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,
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/CAGdCwBu4CVmS3yGcmM9hW0-22Exfm5b72FVA2CQ_h9O_zTCrPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
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/405d98f0-af6a-45b9-8bed-35fc9f99b8ea%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
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/62f18b57-59f8-4da0-91e2-a8d7c28fbd2a%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
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/CAMwjO1GvAnMx3TtO36hxgQN9coOmEKGO%3DJKSrOSs%2BOgGb-8qKQ%40mail.gmail.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
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-7mWWB7OaHbW6SAr_4Ae3GyydvaPp1mmsSBStPSYCrotoyg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Loïc Bistuer]

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

[Anders Steinlein]

Post by Loïc Bistuer

On Jun 23, 2015, at 17:24, Aymeric Augustin <
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

[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

[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

Post by 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

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

Post by 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

Post by 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

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

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

Post by 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

Post by 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

[Aymeric Augustin]

OK, count me as -0 ;-)
--
Aymeric.

On Jun 23, 2015, at 17:24, 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.
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
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.