Re: 1.9 release planning

[Carl Meyer]

Hi Tim,

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

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

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

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

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

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

Carl

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


signature.asc
Description: OpenPGP digital signature

help needed?

[Bernhard Janetzki]

Hello together,
i'm the author of https://github.com/ierror/django-js-reverse - i'd like to 
contribute sth. to django.
Is there e.g. help needed for maintaining the django website? I also have 
knowledge in linux / freebsd server hosting.

Best regards from munich,
Bernhard

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


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: 1.9 release planning

[Chris Foresman]

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

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



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

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

Re: help needed?

[Florian Apolloner]

Hi,

take your pick: https://github.com/django/djangoproject.com/issues :)

Cheers,
Florian

On Monday, April 6, 2015 at 9:38:28 PM UTC+2, Bernhard Ja wrote:
>
> Hello together, 
> i'm the author of https://github.com/ierror/django-js-reverse - i'd like 
> to contribute sth. to django. 
> Is there e.g. help needed for maintaining the django website? I also have 
> knowledge in linux / freebsd server hosting. 
>
> Best regards from munich, 
> Bernhard 
>
>

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

Re: 1.9 release planning

[Aymeric Augustin]

Hello,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-- 
Aymeric.



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

Re: 1.9 release planning

[Shai Berger]

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

Shai.

Re: 1.9 release planning

[Tim Graham]

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

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

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

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

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

Unfortunate /login behavior in 1.8 (and 1.7)?

[Christophe Pettus]

I have a site with a /login URL.  This URL is for customer logins to an 
ecommerce site, and is distinct from the /admin/login to the Django admin.

However, having upgraded from 1.6 to 1.8, it appears that /admin/login is 
getting confused, and running the view associated with the /login URL.  This 
effectively prevents me from logging into the admin.  I assume this has 
something to do with the redirection change in 1.7 for the admin login.

If I change the name of /login to /customer_login, that confusion goes away.

--
-- Christophe Pettus
   x...@thebuild.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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/F262F7CB-69ED-4BE3-B1FD-F1FDECA8591F%40thebuild.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unfortunate /login behavior in 1.8 (and 1.7)?

[Christophe Pettus]

Ignore my silliness... operator error, that the 1.7 change flushed out!

On Apr 6, 2015, at 11:36 PM, Christophe Pettus  wrote:

> I have a site with a /login URL.  This URL is for customer logins to an 
> ecommerce site, and is distinct from the /admin/login to the Django admin.
> 
> However, having upgraded from 1.6 to 1.8, it appears that /admin/login is 
> getting confused, and running the view associated with the /login URL.  This 
> effectively prevents me from logging into the admin.  I assume this has 
> something to do with the redirection change in 1.7 for the admin login.
> 
> If I change the name of /login to /customer_login, that confusion goes away.
> 
> --
> -- Christophe Pettus
>   x...@thebuild.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-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/F262F7CB-69ED-4BE3-B1FD-F1FDECA8591F%40thebuild.com.
> For more options, visit https://groups.google.com/d/optout.

--
-- Christophe Pettus
   x...@thebuild.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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/744EBC05-CA1F-47FF-96A9-767F2441EDFB%40thebuild.com.
For more options, visit https://groups.google.com/d/optout.