Re: 1.9 release planning

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.

Re: 1.9 release planning

For an additional non-core dev data point, I'm also +1 on Loic's 1.10, 1.11, 2.0... plan. Makes it much easier to plan and communicate framework upgrades to clients. On Tuesday, June 23, 2015 at 9:14:25 PM UTC-5, Josh Smeaton wrote: > > I was worried about 1.10 because I wrongly assumed that

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

OK, count me as -0 ;-) -- Aymeric. 2015-06-23 13:23 GMT+02:00 Loïc Bistuer : > > > On Jun 23, 2015, at 17:24, Aymeric Augustin < > aymeric.augus...@polytechnique.org> wrote: > > > > I'm against making changes to the version numbers we've already planned > for and also

Re: 1.9 release planning

2015-06-23 13:23 GMT+02:00 Loïc Bistuer : > > > On Jun 23, 2015, at 17:24, Aymeric Augustin < > aymeric.augus...@polytechnique.org> wrote: > > > > Besides, honestly, 1.10 is just ugly :-) > > I don't really see anything wrong with 1.10+ versions but maybe that's > because

Re: 1.9 release planning

> On Jun 23, 2015, at 17:24, Aymeric Augustin > wrote: > > I'm against making changes to the version numbers we've already planned for > and also against 1.10, 1.11 etc. version numbers. > > Such numbers can easily break version checks that don't expect

Re: 1.9 release planning

+1 to not changing already planned version numbers. - Anssi On Tue, Jun 23, 2015 at 1:24 PM, Aymeric Augustin wrote: > I'm against making changes to the version numbers we've already planned for > and also against 1.10, 1.11 etc. version numbers. > > Such

Re: 1.9 release planning

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

Re: 1.9 release planning

+1 to 1.11 It was an arbitrary decision not to use 2.0 in the first place because we were not going to do special version numbers. Now Y.0 is a special version (dropping backwards compat after the LTS) it makes more sense. Marc On 22 Jun 2015 19:28, "Tim Graham" wrote: >

Re: 1.9 release planning

Done that in https://github.com/django/django/pull/4908 On Monday, June 22, 2015 at 1:35:19 PM UTC-4, Loïc Bistuer wrote: > > We can just leave RemovedInDjango20Warning as an alias (not a subclass) to > PendingDeprecationWarning in 1.8. As long as we don't refer to it in the > rest of the

Re: 1.9 release planning

We can just leave RemovedInDjango20Warning as an alias (not a subclass) to PendingDeprecationWarning in 1.8. As long as we don't refer to it in the rest of the codebase it isn't ambiguous. -- Loïc > On Jun 23, 2015, at 00:21, Collin Anderson wrote: > > People import

Re: 1.9 release planning

People import the warning in order to silence them, right? On Monday, June 22, 2015 at 1:19:51 PM UTC-4, Markus Holtermann wrote: > > +1 -- Going with 1.8, 1.9, 1.10, 1.11 (LTS), 2.0 sounds like a solid > plan. I don't think any of the (Pending)DeprecationWarnings are much of > a public API.

Re: 1.9 release planning

+1 -- Going with 1.8, 1.9, 1.10, 1.11 (LTS), 2.0 sounds like a solid plan. I don't think any of the (Pending)DeprecationWarnings are much of a public API. I've never seen them in the wild. /Markus On Mon, Jun 22, 2015 at 11:20:52AM -0400, Michael Manfre wrote: +1. I really don't like the idea

Re: 1.9 release planning

+1. I really don't like the idea of 2.x being odd. On Mon, Jun 22, 2015 at 10:33 AM, Loïc Bistuer wrote: > Just when we thought we had a winner... I'd like to make a final proposal. > > Instead of delaying adoption of SemVer to 3.0 we could do so in 2.0 by > introducing

Re: 1.9 release planning

It's okay with me. I don't think RemovedInDjango18Warning is much of a public API, but we can mention it's renaming in the minor release notes just in case. On Monday, June 22, 2015 at 10:33:47 AM UTC-4, Loïc Bistuer wrote: > > Just when we thought we had a winner... I'd like to make a final

Re: 1.9 release planning

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

Re: 1.9 release planning

I'm also +1 on the proposal as it stands, and neutral on when the semver versioning should begin. On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote: > > I'm +1 on the Google doc proposal and like Markus, I support relabeling > 1.9 to 2.0 to line the versions up with the new

Re: 1.9 release planning

I'm +1 on the Google doc proposal and like Markus, I support relabeling 1.9 to 2.0 to line the versions up with the new paradigm without the X.1 LTS oddball. Regards, Michael Manfre On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson wrote: > I also like the gdoc as it is.

Re: 1.9 release planning

I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1, 3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and we sacrifice a little bit of strict semver, but it give some nice meaning to the version numbers. On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer

Re: 1.9 release planning

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

Re: 1.9 release planning

Thanks Loic, that helps A LOT! I'm +1 on a semver or semver-ish policy. I don't have a favorite of the proposed. And I'm +-0 on changing e.g. 1.9 to 2.0 or whatever is required to match the new release policy. /Markus On Tue, Jun 16, 2015 at 02:15:59PM +0700, Loïc Bistuer wrote: I've

Re: 1.9 release planning

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

Re: 1.9 release planning

The Google doc has been evolving: https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing On Monday, June 15, 2015 at 3:37:16 PM UTC-4, Aymeric Augustin wrote: > > Le 15 juin 2015 à 15:54, Loïc Bistuer > a écrit : > > > > I'm -0

Re: 1.9 release planning

Le 15 juin 2015 à 15:54, Loïc Bistuer a écrit : > > I'm -0 (borderline -1) on that proposal. I don't think we should compromise > on our historical commitment of deprecating over 2 releases I'm in the same camp as Loïc on this specific point. If we're approaching

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

Of course RemovedInDjango19Warning is also in 1.7 and a lot of docs reference Django 1.9. I'm not enthusiastic about updating all that. On Sunday, June 14, 2015 at 1:43:50 AM UTC+2, Loïc Bistuer wrote: > > > > On Jun 13, 2015, at 20:43, Tim Graham > wrote: > > > > I

Re: 1.9 release planning

> On Jun 13, 2015, at 20:43, Tim Graham wrote: > > I don't have a strong opinion either way on semver, but I think it's a bit > late to rebrand 1.9 as 2.0 considering we've release code and docs with > reference to "RemovedInDjango19Warning". Do you have any thoughts on

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

2015-06-12 18:58 GMT+02:00 Carl Meyer : > I don't get the feeling that the core team is really ready to accept > that length of continued support for deprecated APIs. > Especially if the deprecation and removal is a pre-requisite for implementing a new feature... I'm not

Re: 1.9 release planning

Hi Matt, On 06/11/2015 07:30 PM, Matt Austin wrote: > On 11 June 2015 at 01:37, Collin Anderson wrote: >> >> I'd propose something slightly different, that's very close to our current >> deprecation timeline: >> 1.8 (LTS): No features dropped. >> 1.9: Dropped features

Re: 1.9 release planning

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

Re: 1.9 release planning

On 11 June 2015 at 01:37, Collin Anderson wrote: > > I'd propose something slightly different, that's very close to our current > deprecation timeline: > 1.8 (LTS): No features dropped. > 1.9: Dropped features deprecated in 1.5, 1.6, 1.7 > 2.0: Dropped features deprecated in

Re: 1.9 release planning

I like Colin's proposed schedule. Regards, Michael Manfre On Thu, Jun 11, 2015 at 1:12 AM, Anssi Kääriäinen wrote: > +1 to Collin's release schedule. > > This schedule should make it extremely easy to support "develop using > latest release, maintain using latest LTS". With

Re: 1.9 release planning

+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

Re: 1.9 release planning

Yep, I think Collin's schedule is it. I'm happy with that option and 3rd party apps shouldn't need to add any compatibility shims to support 2 releases -- they just need to ensure they aren't using any deprecated APIs. On Wednesday, June 10, 2015 at 3:48:39 PM UTC-4, Collin Anderson wrote: > >

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

+1 dude!! go for it! On Mon, Jun 8, 2015 at 7:25 PM, Tim Graham wrote: > Any other feedback on the proposal? I could assume no complaints is a good > sign, but some +1's would be easier to interpret. :-) > > > On Monday, June 1, 2015 at 11:09:12 AM UTC-4, Collin Anderson

Re: 1.9 release planning

Any other feedback on the proposal? I could assume no complaints is a good sign, but some +1's would be easier to interpret. :-) On Monday, June 1, 2015 at 11:09:12 AM UTC-4, Collin Anderson wrote: > > I see. I missed the "first upgrade Django to the last release before the > next > LTS (e.g.

Re: 1.9 release planning

I see. I missed the "first upgrade Django to the last release before the next LTS (e.g. upgrade 1.8->1.9->2.0), then upgrade your dependencies to the newer version that supports both 2.0 and 2.1, and then finally upgrade to 2.1." part. Thanks, Collin On Monday, June 1, 2015 at 11:02:01 AM

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

thats great!!! On Mon, Jun 1, 2015 at 7:20 PM, Tim Graham wrote: > I put together a draft proposal in the form of a potential > djangoproject.com blog post. I've enabled commenting in case you have > minor cosmetic comments, but please keep discussion about the content of

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

How about a 8 month release cycle and having a LTS in every two years and supporting the old LTS atleast 3 years from the release date? there will be 3 version between two LTS. On Thursday, March 12, 2015 at 6:13:11 AM UTC+6, Tim Graham wrote: > > With the release of 1.8 coming up, it's time

Re: 1.9 release planning

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

Re: 1.9 release planning

This looks like a good plan to me. The main reason for shortening it before as far as I could tell was the lengthy alpha to final process, which hasn't happened this time and hopefully will be rather less frequent in future. Marc On 7 April 2015 at 00:21, Tim Graham wrote:

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

On Saturday 04 April 2015 21:16:54 Michael Manfre wrote: > On Sat, Apr 4, 2015 at 12:56 PM, Thomas Tanner wrote: > > I think rare LTS releases and frequent (6month) incremental upgrades are > > a good compromise. > > Third-party packages should support LTS releases and at least

Re: 1.9 release planning

On Sat, Apr 4, 2015 at 12:56 PM, Thomas Tanner wrote: > I think rare LTS releases and frequent (6month) incremental upgrades are > a good compromise. > Third-party packages should support LTS releases and at least the latest > Django version. They may drop support for earlier

Re: 1.9 release planning

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

Re: 1.9 release planning

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.

Re: 1.9 release planning

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

1.9 release planning

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