An easier path to upgrade from one LTS release to another

[Abdullah Esmail]

Hello,

I apologize if this has been discussed already. I searched the topics, but didn't find anything.

First, I'd like to thank all of you for the truly amazing framework. I've been using django since 1.0 and it made my life much more easier and enjoyable and _stable_.

The reason why I love django is that stability is a high priority, backward-compatibility is well maintained and clear, crystal-clear and extra-detailed documentation, the "batteries-included" aspect, based on python, and the steady and stable evolution of the framework. Everything is well put together in an almost-perfect package. Thank you.

To my main issue, have you explored the possibility of creating a direct path from one LTS release to the next?

I think the "official" way of doing this now is to go through all releases in-between (1.4 -> 1.5 -> 1.6 -> 1.7 -> 1.8).

It would be really great if there was a direct LTS-to-LTS path (1.4 -> 1.8).

I'm not sure if the new system check framework can play a role here to make this easier than before.

This might add a whole new layer of complexity and extra work, but I believe it's worth it.

If it makes any difference, I don't mind helping with this and actually bringing this feature to life.

I'm not that familiar with the internals of django, but I'm willing to learn and get my hands dirty.

I guess I should ask, is there a good reason why there is no direct upgrade path between LTS releases?

Do you guys think it's not worth the extra effort and the current way is an acceptable trade-off?

Thank you,

[Anssi Kääriäinen]

One approach worth consideration is dropping deprecated features only
after next LTS. This would mean that any non-deprecated feature that
is available in current LTS will also be available (but possibly
deprecated) in the next LTS. This should make a development model
where code is developed using latest stable release, and supported
using latest LTS a lot easier.

I don't belileve we can offer an official LTS-to-LTS upgrade guide
(maintaining one is simply too much work). You can of course try to do
that, but you'll likely get a better result by upgrading one point
release at a time.

- 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/96e73e82-93fe-4ef7-92c4-ba67abb35b37%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Marc Tamlyn]

I'm not sure that would be a wise move - for people who don't keep up with deprecation warnings but otherwise move one version at a time it would make upgrading from an LTS to the following release 3 times harder than normal, encouraging stagnation. This also affects third party applications who will have similar problems.

Marc

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALMtK1E-F8i4_%2BYLH6KRzWMvuJEmr8geDDU9mUY9MFRudhLw0Q%40mail.gmail.com.

[Tom Evans]

What would this feature look like? In order to go from one LTS to the
next LTS, you will need to do various things in turn, in order to
reflect the reality of changing 4 (or however many) minor versions one
at one time.

The easiest way to do that is to step through each of the intermediate
versions release notes in turn, applying the changes for that release
before moving on to the next one. I don't see what advantage collating
them all in to one document would have, given that you will still need
to do each set of steps in turn.

Cheers

Tom

PS: We are following this approach at $JOB - stick to LTS until the
next LTS and then upgrade via each minor release. Or I guess "will
be", 1.8 being only the second LTS ;)

[Anssi Kääriäinen]

On Thu, May 7, 2015 at 11:34 AM, Marc Tamlyn <marc....@gmail.com> wrote:
> I'm not sure that would be a wise move - for people who don't keep up with
> deprecation warnings but otherwise move one version at a time it would make
> upgrading from an LTS to the following release 3 times harder than normal,
> encouraging stagnation.

The other side of this coin is that you get painless upgrades to the
latest LTS from the latest stable version. So, with a bit of
exaggeration, one could say that our current model encourages
stagnation to non-LTS versions.


- Anssi

[Marc Tamlyn]

You only get painless upgrades from one LTS to the next *if* you don't have any deprecation warnings in your code on the previous LTS. Whilst the "getting it working" step from one LTS direct to the next should be fairly easy, you're likely to be faced with just as large a set of deprecation issues on that new LTS issues you would have had to fix to get it working. This does have some benefit for a quick update for security support or similar, however I think there's a good chance it will make the *next* LTS more painful as those warnings will not have been eliminated.

Then again, I don't work in an LTS environment, and no one has been working in such a setup with django through several LTS versions to see what happens.

--
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/CALMtK1EC%2B9nakK2MjW%2B5mV3Nyt10XbQi2vTw6_WCfDwQ2GQLJQ%40mail.gmail.com.

[Tim Graham]

I think there is some merit to reconsidering the deprecation schedule as Anssi suggests. What I have seen is that most third-party apps didn't consider dropping support for the previous LTS (1.4) until the next LTS (1.8) was released. This meant that all these projects had to implement their own compatibility shims (instead of using Django's) once they wanted to add support for Django 1.6+ because the compatibility shims for deprecated features in 1.4 were dropped in Django. This resulted in ugly code with lots of conditional version branches, etc. I'll keep thinking about this as we decide the release schedule going forward.

[Carl Meyer]

On 05/07/2015 08:53 AM, Tim Graham wrote:
> I think there is some merit to reconsidering the deprecation schedule as
> Anssi suggests. What I have seen is that most third-party apps didn't
> consider dropping support for the previous LTS (1.4) until the next LTS
> (1.8) was released. This meant that all these projects had to implement
> their own compatibility shims (instead of using Django's) once they
> wanted to add support for Django 1.6+ because the compatibility shims
> for deprecated features in 1.4 were dropped in Django. This resulted in
> ugly code with lots of conditional version branches, etc. I'll keep
> thinking about this as we decide the release schedule going forward.

I agree with this. I think by far the biggest thing we could do to make
it easier to go from LTS to LTS is to make it easier for third-party
apps to support two LTS releases at once. Guaranteeing that no API which
is un-deprecated in one LTS will be removed until after the following
LTS would make that massively easier.

Carl

[Tai Lee]

This sounds good. But will it significantly slow down the rollout of new features into Django that require deprecation? Also, could features that are deprecated in an LTS be dropped in the next non-LTS release? e.g. if 1.8 still had a feature that was deprecated in 1.5, could it finally be removed in 1.9?

[Tim Graham]

Do we need to make it easy to support two LTS releases at once? For example, at this point in time I expect projects to drop 1.4 support when adding 1.8 support, not try to support both given that 1.4 will be EOL in < 6 months. Assuming the answer is no, practically, it might mean keeping around the deprecation shims added in an LTS release a bit longer than usual -- otherwise no change to the current 2 version deprecation if we adopted the 8 month schedule:

1.8 - April 2015 - LTS
1.9 - Dec. 2015 - (drop features deprecated in 1.7) [1.7 no longer supported]
2.0 - Aug. 2016 -
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]

I think this change would be worth it.

By the way, the current feedback from the survey regarding the release schedule:

Every 6 months	519	31.7%
Every 8 months	265	16.2%
Every 9 months	301	18.4%
Every 12 months	505	30.9%

[Carl Meyer]

Hi Tai,

On 05/07/2015 10:20 PM, Tai Lee wrote:
> This sounds good. But will it significantly slow down the rollout of new
> features into Django that require deprecation?

No, because it would only delay the removal of deprecated features, not
prevent the initial deprecation. The only cost here is the added
maintenance cost of having to keep deprecated code paths around a bit
longer. This cost is non-zero, but in most cases it's quite manageable.

> Also, could features that
> are deprecated in an LTS be dropped in the next non-LTS release? e.g. if
> 1.8 still had a feature that was deprecated in 1.5, could it finally be
> removed in 1.9?

Yes, in the way that I'd envisioned it, a feature which is deprecated in
an LTS could be dropped on the normal schedule (since anyone for whom
that LTS is their oldest supported version can upgrade to the
replacement for that deprecated API.)

Carl

[Carl Meyer]

Hi Tim,

On 05/08/2015 08:28 AM, Tim Graham wrote:
> Do we need to make it easy to support two LTS releases at once? For
> example, at this point in time I expect projects to drop 1.4 support
> when adding 1.8 support, not try to support both given that 1.4 will be
> EOL in < 6 months. Assuming the answer is no, practically, it might mean
> keeping around the deprecation shims added in an LTS release a bit
> longer than usual -- otherwise no change to the current 2 version
> deprecation if we adopted the 8 month schedule:
>
> 1.8 - April 2015 - LTS
> 1.9 - Dec. 2015 - (drop features deprecated in 1.7) [1.7 no longer
> supported]
> 2.0 - Aug. 2016 -
> 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]
>
> I think this change would be worth it.

I think this change would definitely help.

Just to play devil's advocate for a moment, I do think there would be
some value in going one step further and making it easier for
widely-used third-party apps to actually straddle two LTS releases.

Philosophically it seems reasonable that, as a third-party project
author, I ought to be able to have a simple supported-versions policy of
"support every currently-supported Django version", without having to
work around removed APIs. This always used to be possible (without
contortions) before the introduction of the LTS releases.

Also, having to "sync" the upgrades of your dependencies with your
upgrade of Django (because there is no version of the dependency that
supports both the old and new Django version) can combinatorially
explode the complexity of the upgrade. (We saw this play out with Django
1.6->1.7 and South->migrations.) It's much better if you can do the two
upgrades separately (by which I mean, "have a working version of your
project that passes all its tests in between each step").

OTOH, even your proposal makes it possible to do them separately; you'd
just have to 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.

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.

So all in all it probably makes more sense to try your less-drastic
proposal first.

> By the way, the current feedback from the survey regarding the release
> schedule:
> Every 6 months 519
> 31.7%
> Every 8 months 265 16.2%
> Every 9 months 301 18.4%
> Every 12 months 505 30.9%

Wow, it would be hard to design a less-helpful result :-) It seems that
we have a bimodal distribution: there's the "release early and often"
camp and the "don't release very often, upgrading is too hard" camp, and
they are roughly evenly balanced.

Carl

[Aymeric Augustin]

Hello,

On 8 mai 2015, at 17:54, Carl Meyer <ca...@oddbird.net> wrote:
>
> On 05/07/2015 10:20 PM, Tai Lee wrote:
>> This sounds good. But will it significantly slow down the rollout of new
>> features into Django that require deprecation?
>
> No, because it would only delay the removal of deprecated features, not
> prevent the initial deprecation. The only cost here is the added
> maintenance cost of having to keep deprecated code paths around a bit
> longer. This cost is non-zero, but in most cases it's quite manageable.

There are some cases where, in order to implement a new feature, you
have to wait until a deprecation completes.

(In such cases, I have to admit that I try to skip the deprecation path and
make a backwards-incompatible change, but that isn’t a good practice.)

See my current work on removing database adopters for an example.

--
Aymeric.