Django versioning and breaking changes policy

[Bernhard Posselt]

Hi guys :)

I'm maintaining a Django project that uses 6 apps:

* djangorestframework,

* django-parler (database translations),

* django-allauth (openid & richer account settings)

* django-recaptcha2 (simple recaptcha widget)

* django-csp

* django-cors-middleware

Each time a new Django version is published it takes me at least a few
weeks to upgrade. The reason is that each release breaks something in
the apps that I use. Code that I wrote myself can usually be fixed
pretty quickly.

Personally I don't think that the number of dependencies is excessive.
Furthermore I think that Django developers want to offload as much
functionality as possible to thirdparty apps to improve maintainability
so I doubt that I'm the only one with these issues.

I know that deprecating and cleaning up things is *very* important to
keep the framework alive however was it ever considered to tune down the
frequency of breaking changes (like only remove features in a new LTS
release)?

Apart from that would it be possible to adopt semver? If you had
followed semver closely, each 1.x release would have actually been a
major release (e.g. 1.1 -> 2.0.0, 1.2 -> 3.0.0) and your point releases
would need to contain three version numbers (e.g. 1.11.0 and not 1.11).

I know that this versioning approach leads to very high version number
in a short amount of time but that's essentially what Django does:
breaking compat with each release :)

[Aymeric Augustin]

Hello,

As far as I can tell, recent modifications to the release process means it will meet your expectations going forwards.

Take a look at https://docs.djangoproject.com/en/dev/internals/release-process/ for details.

Best regards,

-- 

Aymeric.

PS - https://twitter.com/fwiles/status/849161016734830592

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7fde82bd-352d-9946-2cbc-699f04bd8773%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Tobias McNulty]

Hello Bernhard,

In my experience, Django strikes a good balance between adding new features without moving so quickly that it's impossible to keep up. That being said, third-party packages *can* vary widely in the speed with which they add support for new Django versions after a new major release.

What are some changes in Django over the past few releases that you felt were too significant or costly to address?

Tobias

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7fde82bd-352d-9946-2cbc-699f04bd8773%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Tobias McNulty
Chief Executive Officer

tob...@caktusgroup.com
www.caktusgroup.com

[Bernhard Posselt]

Hi Tobias,

my impression is that as a developer you can keep up with the changes
pretty well and I don't think it's related to features being too costly
to address. The main issue is really third-party code.

The only thing that I can currently think of as a comparison is the
Angular 1.x branch: If there were breaking changes then there were very
few and I don't think I've ever had issues with third-party plugins
breaking due to upgrading an Angular 1.x release to a new "major"
version. Yeah, I know that it's probably hard to compare the two
frameworks and they rewrote everything from scratch in v2 and basically
broke all code, but the 1.x parts were pretty well done at least :)

Thinking about it I think the main issue is probably the high number of
breaking interfaces: it's not like a bump from 1.10 to 1.11 changes two
interfaces but it's a whole array of things in all kinds of components.
This makes it very likely that an extension is affected by a breaking
change.

In addition to that I kinda feel like when using Django nowadays I can't
really use it "as is", out of the box. 5-7 years ago when webdevelopment
was about serverside templating & forms and very little JavaScript
Django was almost perfect and you needed maybe 1 or 2 third-party libs
to create a full website. Nowadays you need REST apis (DRF, CORS
middleware) and also want to employ a CSP to lock things down.

So TL;DR I suppose:

* web development got more complex
* Django did not move fast enough (IMHO) to support "modern" websites,
responsibilities were moved to third-party libs
* you therefore need more third-party libs which are usually (there are
ofc exceptions) maintained worse than Django
* there are a lot of breaking changes in interfaces each release so
upgrading hurts a lot

I know its a difficult problem so I don't know what the solution
could/should be and I'm interested in opinions :)

>> email to django-develop...@googlegroups.com.
>> To post to this group, send email to django-d...@googlegroups.com.

[Bernhard Posselt]

Oh wow, haven't seen that yet, thank you :)

Just make sure to follow the semver spec closely if you transition to
semver, because it can cause issues for parsers. Also the spec is more
restrictive than you'd think with regards to syntax (source: working
with semver in my current Django project)

On 04/04/2017 11:11 PM, Aymeric Augustin wrote:
> Hello,
>
> As far as I can tell, recent modifications to the release process means it will meet your expectations going forwards.
>

> Take a look at https://docs.djangoproject.com/en/dev/internals/release-process/ <https://docs.djangoproject.com/en/dev/internals/release-process/> for details.
>
> Best regards,
>

[Curtis Maloney]

See? This is exactly what I told you you could expect ... to be shown
the new release process details :)

[For those playing at home, Bernhard raised this concern on IRC first,
and I recommended bringing it here. He expressed concern about being
roasted, and I predicted someone would introduce him to the details of
the new release process :)]

--
C

[Aymeric Augustin]

Django doesn't transition to semver.

It keeps its own versioning scheme but reuses some good ideas from semver.

-- 

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 https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4dc89ce1-4e93-a7c0-c3a7-b464a889e6ca%40gmail.com.

[James Pic]

I think people are always going to run into such kind of issues until they decide to add django-master to their test matrix​, so that each dependency and project should always have the chance to be ready for the next version of Django "0day". But perhaps I'm missing something.

Best
James