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.

[Thorsten Sanders]

Am 04.04.2015 14:30, schrieb Tim Graham:

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

I started to use django years ago and I like it but these fast releases result in quite some projects running django version not getting any security fixes anymore, yes there is the LTS but if I start a new project I use the current version to get features not being in the LTS version and I dont have the time to upgrade all projects to the current and do in depth testing if all works like expected and such a fast release cycle makes it even worse, if there is such an fast release cycle at least older version should get security fixes too otherwise its kinda unattractive to use it.

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

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

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

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

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0df00068-112f-4e98-9201-78d6ba9ef97c%40googlegroups.com.
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.

[Michael Manfre]

On Sat, Apr 4, 2015 at 12:56 PM, Thomas Tanner <tan...@gmx.net> wrote:

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

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

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

 

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

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

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/552017D7.6020907%40gmx.net.

[Shai Berger]

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

I agree fully.

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

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

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

Shai.

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

[Carl Meyer]

Hi Tim,

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

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

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

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

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

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

Carl

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

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

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0df00068-112f-4e98-9201-78d6ba9ef97c%40googlegroups.com.

[Shai Berger]

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

This was decided a little before 1.7 was released: the version after 1.9 will
be called 2.0, but it is not going to break things more than earlier releases
(there are already warning classes named RemovedInDjango20Warning and
RemovedInDjango21Warning in the sources, anticipating the releases after 1.9).

Shai.

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

[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

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/56675028-6c26-4f72-9491-98f2db0f529e%40googlegroups.com.

[Markus Holtermann]

On Tuesday, April 7, 2015 at 1:21:20 AM UTC+2, Tim Graham wrote:

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

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

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

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

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

 

Markus

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

[Collin Anderson]

On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:

How about

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

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

[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

[Asif Saifuddin]

thats great!!!

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/MTvOPDNQXLI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.

To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5e38433f-f499-483c-88aa-0d2744fad9cb%40googlegroups.com.

[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

[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

[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

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

[Asif Saifuddin]

+1 dude!! go for it!

--

You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/MTvOPDNQXLI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d35a73d6-0974-403c-b1dd-dc12f3a8a21a%40googlegroups.com.

[Aymeric Augustin]

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

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

--
Aymeric.

[Collin Anderson]

Hi All,

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

On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:

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

I'd propose something slightly different, that's very close to our current deprecation timeline:

1.8 (LTS): No features dropped.

1.9: Dropped features deprecated in 1.5, 1.6, 1.7

2.0: Dropped features deprecated in 1.8

2.1 (LTS): No features dropped. 

2.2: Dropped features deprecated in 1.9, 2.0

2.3: Dropped features deprecated in 2.1

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

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

Collin

[Collin Anderson]

On Friday, May 8, 2015 at 12:12:37 PM UTC-4, Carl Meyer wrote:

And there is a significant added maintenance cost to my proposal 
compared to yours. Dropping deprecated APIs in the release after an LTS 
means we still have to support those APIs for three more years (possibly 
for four or five years after they were first deprecated). Dropping them 
_in_ the LTS release shortens that window drastically.

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

Thanks,

Collin

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

[Carl Meyer]

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

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

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

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

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

Carl

[Collin Anderson]

Hi Tim,

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

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

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

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

Thanks,

Collin

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

[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

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

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

> To unsubscribe from this group and stop receiving emails from it, send an

> email to django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/django-developers/bbc5256e-f5e9-445d-9d35-601a55568b30%40googlegroups.com.

[Michael Manfre]

I like Colin's proposed schedule.

Regards,

Michael Manfre

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

[Matt Austin]

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

Hi everyone,

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

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

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

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


Cheers,

--
Matt

[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

[Carl Meyer]

Hi Matt,

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]

2015-06-12 18:58 GMT+02:00 Carl Meyer <ca...@oddbird.net>:

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

[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

> --
> You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/f887421b-c470-491f-b5f0-a12af397bfe1%40googlegroups.com.

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

[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

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/fc7744d0-20ed-43f0-8cfa-860494b32a0c%40googlegroups.com.

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

[Loïc Bistuer]

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

Currently we have:

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

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

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

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

--
Loïc

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

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

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

> --
> You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4c636d6d-4365-48dc-932a-5a67cec44a51%40googlegroups.com.

[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

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8FD2862C-D50D-44B9-8517-8C37417BF8BB%40gmail.com.

[Aymeric Augustin]

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

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

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

--
Aymeric.

[Tim Graham]

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

[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

[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

>--
>You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
>To post to this group, send email to django-d...@googlegroups.com.
>Visit this group at http://groups.google.com/group/django-developers.

>To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/B8FE1DF4-1542-465B-B3DE-A7CA0DE5C3BB%40gmail.com.

>For more options, visit https://groups.google.com/d/optout.

--

[Carl Meyer]

Thanks Loïc,

On 06/16/2015 01:15 AM, Loïc Bistuer wrote:
> I've attempted to summarize the history of this thread. Note that I
> marked as +1 any generally positive feedback towards a given
> proposal, please correct if you feel misrepresented.
>

[snip]

>
> # Third iteration:
>
> 5/ Switching to Semantic Versioning
>
> Donald mentioned SemVer on IRC a few days ago. Since then various
> proposal were made to reconcile it with our release policy. So far
> Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to
> various proposals in that direction but I don't think we have yet
> reached consensus on a specific one. Tim updated the Google doc to
> reflect my latest proposal, so including me that's 2 formal +1 for
> it, but I'd say we should wait for at least a couple more votes
> before taking it to the technical board.
>
> Refs: - http://semver.org/ - Carl's analysis
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
>
>
- Ryan's proposals
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
> - Loïc's proposal
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ

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

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

Carl

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

[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

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Josh Smeaton]

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

[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

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/79aae5a5-58dd-4f05-a6dd-35685e06ebb5%40googlegroups.com.

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

[Michael Manfre]

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

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.

[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

>To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAGdCwBu4CVmS3yGcmM9hW0-22Exfm5b72FVA2CQ_h9O_zTCrPQ%40mail.gmail.com.

[Collin Anderson]

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

[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

> To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/405d98f0-af6a-45b9-8bed-35fc9f99b8ea%40googlegroups.com.

[Tim Graham]

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

[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

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/62f18b57-59f8-4da0-91e2-a8d7c28fbd2a%40googlegroups.com.

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

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.

[Anssi Kääriäinen]

+1 to not changing already planned version numbers.

- Anssi

> https://groups.google.com/d/msgid/django-developers/CANE-7mWWB7OaHbW6SAr_4Ae3GyydvaPp1mmsSBStPSYCrotoyg%40mail.gmail.com.

[Loïc Bistuer]

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

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

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

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

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

--
Loïc

[Anders Steinlein]

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

[Aymeric Augustin]

OK, count me as -0 ;-)

-- 

Aymeric.

2015-06-23 13:23 GMT+02:00 Loïc Bistuer <loic.b...@gmail.com>:

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/76292589-2340-46DB-BB4D-F38414332B2D%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Aymeric.

[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

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

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