Django 1.6/1.8 support

[Tim Graham]

Django 1.8 is scheduled to be released in about 2 months at which point 1.6 will no longer be supported. If I worked on a branch to add 1.8 support and drop 1.6 support would be it accepted to merge around the time 1.8 is released? Since features deprecated in 1.6 are removed in 1.8, it will be easier if we don't have to support more than two versions of Django.

[Iacopo Spalletti]

I don't think we can drop 1.6 support so soon.
I already investigated preliminary 1.8 support, but currently we need
some upstream package update to make it work on 1.8 (hvad being the most
important: django CMS itself does not depend on hvad, but the testsuite
does).

--

Iacopo Spalletti

[Tim Graham]

Could you give some ideas behind the thinking that it's too soon to drop 1.6 support? For example, if a project wants to use Django 1.6 why can't they stick with django-cms 3.0.X? Do you find that upgrading django-cms on your projects is much easier than upgrading Django? I didn't see any planned release dates on the django-cms roadmap [1] so obviously that would affect this decision.

As you know, I've been working on patches to cleanup django-cms from when it supported more than two version of Django. This is quite a lot of effort (first introducing the shims and then removing then) and I'm wondering if it's a path the team wants to down again? As Django 1.8 is the next LTS, my idea would be to designate some version of django-cms as a matching LTS, but on the "develop" branch, don't try to maintain compatibility with all versions of Django until Django's next LTS.

I'm curious to get feedback on this idea and would be happy to dialog more on it. Alternatively, I am thinking maybe we should alter Django's own LTS policy in some way so that third-party packages like django-cms don't end up in this situation of needing to support more than 2 version of Django.

https://github.com/divio/django-cms/wiki/Roadmap

[Martin Koistinen]

Hi Tim,

We've only just started supporting 1.7 as of 3.0.7, which was pretty recent. Given that and the fact that South and pip are both going through their own changes/deprecations, I worry that it'll be difficult for anyone to get the right combination of things to do an install. Lol.

We only introduced Django 1.7 support less than 2 months ago, and it is proving to be a struggle for a lot of our users, especially as there are a lot of 3rd party tools still getting updated to support 1.7. It doesn't seem right to abandon 1.6 so quickly, if only to provide enough time for the plugin author's to support 1.7 first. I would think that 1.8 support would come in a cms 3.2 release and at that point, we'd drop support for 1.6... but, this is just my opinion, nothing official.

Best,

- Martin

[Iacopo Spalletti]

On 23/01/2015 20:53, Tim Graham wrote:
> Could you give some ideas behind the thinking that it's too soon to drop
> 1.6 support? For example, if a project wants to use Django 1.6 why can't
> they stick with django-cms 3.0.X? Do you find that upgrading django-cms
> on your projects is much easier than upgrading Django? I didn't see any
> planned release dates on the django-cms roadmap [1] so obviously that
> would affect this decision.
>
> As you know, I've been working on patches to cleanup django-cms from
> when it supported more than two version of Django. This is quite a lot
> of effort (first introducing the shims and then removing then) and I'm
> wondering if it's a path the team wants to down again? As Django 1.8 is
> the next LTS, my idea would be to designate some version of django-cms
> as a matching LTS, but on the "develop" branch, don't try to maintain
> compatibility with all versions of Django until Django's next LTS.
>
> I'm curious to get feedback on this idea and would be happy to dialog
> more on it. Alternatively, I am thinking maybe we should alter Django's
> own LTS policy in some way so that third-party packages like django-cms
> don't end up in this situation of needing to support more than 2 version
> of Django.
>
> https://github.com/divio/django-cms/wiki/Roadmap

Views expressed here are just my own, as there hasn't been any formal
discussion on the technical board on this topic.

django CMS 3.1 is a stability release due in a couple of months (see
https://github.com/divio/django-cms/milestones) that aims to improve the
overall experience with django CMS 3 and tackle issues that cannot be
solved in 3.0.x branch (as the concurrency issues caused by mptt).
Upgrade to 3.1 will be (hopefully) painless (the two deprecated features
that's going to be removed have a clear upgrade path with very little
changes in custom code).

Django 1.7 brought in-core migrations, which is a huge step ahead and is
a fundamental goal to improve the Django ecosystem, however 1.6 / south
is still widely adopted, and 1.6 -> 1.7 upgrade it's not an easy task,
especially in large projects.

Given the scope and timing of django CMS 3.1 I think we should really
try hard to avoid removing Django 1.6 support.

>
> On Friday, January 23, 2015 at 7:35:37 AM UTC-5, yakky wrote:
>
> Il 22/01/2015 18:22, Tim Graham ha scritto:
> > Django 1.8 is scheduled to be released in about 2 months at which
> point
> > 1.6 will no longer be supported. If I worked on a branch to add 1.8
> > support and drop 1.6 support would be it accepted to merge around
> the
> > time 1.8 is released? Since features deprecated in 1.6 are
> removed in
> > 1.8, it will be easier if we don't have to support more than two
> > versions of Django.
> >
>
> I don't think we can drop 1.6 support so soon.
> I already investigated preliminary 1.8 support, but currently we need
> some upstream package update to make it work on 1.8 (hvad being the
> most
> important: django CMS itself does not depend on hvad, but the testsuite
> does).
>
> --
>
> Iacopo Spalletti
>

> --
> You received this message because you are subscribed to the Google
> Groups "django CMS developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-cms-devel...@googlegroups.com
> <mailto:django-cms-devel...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.


--
Saluti

Iacopo Spalletti

[John-Scott]

What would the timeline be then for Django 1.8 support? Can we immediately start ripping out deprecated code and 'ugly hacks' in develop once 3.1 is cut?

I think Tim's original point of trying to move django-cms to a codified and more sane support policy still stands (or at least none of the above comments really seem to be in conflict with it). If django-cms similarly makes an LTS release for conservative users that tracks Django LTS, this doesn't or shouldn't prevent innovation or keeping pace with current upstream versions in the develop branch or in non-LTS releases. Absent some kind of policy, it doesn't seem sustainable or a valuable use of volunteer time to continue to expect contributors to write code that spans entire deprecation cycles upstream or to support versions of Django that are no longer supported upstream. 

Are the users who are maintaining older sites on 1.6 squeakier wheels than those of us building new projects? I'm not on IRC as much, but have noticed far more complaints about django-cms 2.x -> 3.0.x than anything Django 1.7 related. As Tim pointed out, users can safely stay on 3.0.x, no one is forcing them to upgrade. If they really want/need the latest and greatest, the OSS way is for them to roll up their sleeves and fix or remove outdated dependencies. That's what I did to bring fuller Django 1.7 support to django-cms and related plugins.

Whatever policy is arrived at, I think we'd need to apply the same to at least the Divio hosted plugins as well to bring clarity there too. Right now there are very confusing version numbers that indicate nothing (0.1 for mature plugins that lived in core for years, etc.). This wouldn't prevent innovation or bug fixes but would be great to have clarity on which django-cms version they are designed to work with.

Thanks,

John-Scott

> an email to django-cms-developers+unsub...@googlegroups.com
> <mailto:django-cms-developers+unsub...@googlegroups.com>.

[Tim Graham]

Yes, I think it would be great if the technical board could provide answers to the questions John-Scott has put forward and adopt a general policy so the community knows what to expect.

[Iacopo Spalletti]

On 23/02/2015 21:38, Tim Graham wrote:
> Yes, I think it would be great if the technical board could provide
> answers to the questions John-Scott has put forward and adopt a general
> policy so the community knows what to expect.

As you know, the django CMS core team is primarly a group of heavy
django CMS users and we strive to provide the best CMS platform for
Django, for us and other users.

We're discussing this, especially in term of sustainability and
predictability.
We're working to make sure 3.1 will have a clear policy in terms of:
- Django version support policy
- django CMS release policy

As technical board we're also discussing about providing a list of
"core" django CMS plugins which the django CMS core team maintain at
least at the same quality level and the same support policy of django
CMS, which will also be used in the django CMS tests.

This said, with a little help and support I think we'll be able to
provide Django 1.8 support in 3.1 (hvad, usually the major roadblock for
supporting Django version, has released a 1.8 compatible version); 3.1
will still support Django 1.6, anyway, to help a smoother transition.

Thanks for your feedback and your contribution!

> <https://github.com/divio/django-cms/milestones>) that aims to

> > an email to django-cms-devel...@googlegroups.com
> > <mailto:django-cms-devel...@googlegroups.com>.

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

> <https://groups.google.com/d/optout>.
>
>
> --
> Saluti

>
> Iacopo Spalletti
>
> --
> You received this message because you are subscribed to the Google
> Groups "django CMS developers" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to django-cms-devel...@googlegroups.com
> <mailto:django-cms-devel...@googlegroups.com>.

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


--

Iacopo Spalletti

Nephila s.a.s. - Firenze
Telefono: +39 055 5357189
Assistenza Tecnica: +39 055 3985730
http://nephila.it

[Tim Graham]

I see that the core team decided that Django 1.6 will be supported in the next release series (3.2) too: https://github.com/divio/django-cms/wiki/Core-developer-meetings--agendas

I'm curious about the rationale for this as maintaining Django 1.6 compatibility (and Python 2.6) is not trivial (see https://github.com/divio/django-cms/pull/3706 for an example), and upstream support has ended for these Python/Django versions. In my view, if a project insists on using these old versions, it can use an old version of django-cms too. Continuing to promote the use of unsupported packages isn't responsible from a security perspective.

[Daniele Procida]

On Sat, Jul 18, 2015, Tim Graham <timog...@gmail.com> wrote:

>I see that the core team decided that Django 1.6 will be supported in the
>next release series (3.2) too:
>https://github.com/divio/django-cms/wiki/Core-developer-meetings--agendas
>
>I'm curious about the rationale for this as maintaining Django 1.6
>compatibility (and Python 2.6) is not trivial (see
>https://github.com/divio/django-cms/pull/3706 for an example), and upstream
>support has ended for these Python/Django versions.

One reason was that we didn't alert our users when we released 3.1 that we'd be dropping support for 1.6.

Another is that various projects that we need to support are still on 1.6, and keeping 1.6 support gives them an easier upgrade path.

> In my view, if a
>project insists on using these old versions, it can use an old version of
>django-cms too. Continuing to promote the use of unsupported packages isn't
>responsible from a security perspective.

It's not really that they insist, but that they in turn have dependencies, or sometimes dependencies that have dependencies, that still require 1.6. It can take complex projects quite a while before all the moving parts catch up (by which point it's often time to change gear again).

It's not ideal, and we're not recommending that people use 1.6. We had to rewrite the recent security patches to apply them to some 1.6-based projects.

Daniele

[Tim Graham]

Not knowing the specific details of your projects, I'm unsure what the "easier upgrade path" means. Why not make upgrading Django priority #1 on projects running django-cms 3.1, then once you are on 1.7+ upgrade to a newer of django-cms? Maybe you would at least consider sharing your unofficial packages of Django 1.6 so that others could benefit from them. Also just wanted to add that having to debug issues on older, unsupported versions discourages me from contributing.

Anyway, in light of Django's roadmap [1], I hope the cms team might consider adopting a more formal Django support policy that doesn't require active development of new versions of django-cms on unsupported versions of Django. Alternatively, just state that the core team determines the policy "as we go" based on needs of their own projects. Just give some guidance to the community. Thanks!

[1] bottom of https://www.djangoproject.com/download/

[Jonas Obrist]

I agree with Tim here. 

One one more thing to consider, staying on 1.6 means supporting Python 2.6, which makes Py3/2 compatibility a lot harder. Supporting 2.7 upwards is fairly easy, but 2.6 makes it unnecessarily difficult.

[Daniele Procida]

On Wed, Jul 22, 2015, Tim Graham <timog...@gmail.com> wrote:

>Not knowing the specific details of your projects, I'm unsure what the
>"easier upgrade path" means. Why not make upgrading Django priority #1 on
>projects running django-cms 3.1, then once you are on 1.7+ upgrade to a
>newer of django-cms?

Ha, you'd be surprised how many #1 priorities there seem to be sometimes...

By "an easier upgrade path" I mean for example a bit of extra breathing space, or being able to update some particular component without having to update another at the same time.

>Maybe you would at least consider sharing your
>unofficial packages of Django 1.6 so that others could benefit from them.

That's a good suggestion; I shall mention it.

>Also just wanted to add that having to debug issues on older, unsupported
>versions discourages me from contributing.
>
>Anyway, in light of Django's roadmap [1], I hope the cms team might
>consider adopting a more formal Django support policy that doesn't require
>active development of new versions of django-cms on unsupported versions of
>Django. Alternatively, just state that the core team determines the policy
>"as we go" based on needs of their own projects. Just give some guidance to
>the community. Thanks!

We have an unexpected issue in the core team at present. In the past year, three key members of the core team have either joined Divio or are now working closely with Divio. There's now only one active member of the core team who's not involved with Divio, and he wasn't able to attend the recent meeting. Another perspective would probably have helped us on that occasion.

Through circumstances, the team represents a narrower set of perspectives than before, and that's not to our advantage. We were already aware of this as a potential issue, and have tried to co-opt new core team members from the community.

We *don't* want django CMS to represent only one set of needs or perspectives, and especially not merely the needs of a particular moment, and we know that it will be better for the project and the product if we can expand the core team and the community of contributors to include more of them - we're still looking.

Daniele

[John-Scott]

An easy way to get outside perspectives would be to solicit them here on the django-cms-developers mailing list. Any reason to not bring these kinds of topics up in advance here so the broader community of contributors might have a chance to contribute? I'm sure you didn't mean it this way but your comments about the core developer situation seemed to imply that only core developers can have input on decision making and the current situation will persist until someone new is added to that team. (Tim seems an obvious candidate although I'm sure he has his hands full.)

As a sporadic contributor over the last 5 years, it does seem sometimes like there's a secret back room where the big decisions are made. I follow the mailing lists, I sometimes check in on IRC and I try to track development on Github. But it still seems like I'm always finding out after the fact when major design decisions have been made. Is there some other forum I should be tracking if I want to participate or at least witness the discussion in real time? I don't expect to have final say, veto powers or commit rights, but having a voice would be nice. As it is, I feel that my only opportunity to contribute is to fix bugs in features that have already been decided on but rarely feel that I can chime in on whether the feature should exist or not.

Apologies if this was too far off topic. I don't mean to malign anyone's motives. It just seems that some of the issues you mention (echo chamber effect) are easily solvable with a little community outreach and not contingent on finding another core dev outside of Divio's realm.

Thanks,

John-Scott

[Daniele Procida]

On Thu, Jul 23, 2015, John-Scott <john.scot...@gmail.com> wrote:

>An easy way to get outside perspectives would be to solicit them here on
>the django-cms-developers mailing list. Any reason to not bring these kinds
>of topics up in advance here so the broader community of contributors might
>have a chance to contribute? I'm sure you didn't mean it this way but your

>comments about the core developer situation seemed to imply that *only *core

>developers can have input on decision making and the current situation will
>persist until someone new is added to that team. (Tim seems an obvious
>candidate although I'm sure he has his hands full.)
>
>As a sporadic contributor over the last 5 years, it does seem sometimes
>like there's a secret back room where the big decisions are made. I follow
>the mailing lists, I sometimes check in on IRC and I try to track
>development on Github. But it still seems like I'm always finding out after
>the fact when major design decisions have been made.

It's extremely helpful to have this kind of feedback, though disappointing, because it shows that we're not succeeding in some of our aims.

To make things clear, this is *not* how we want people to feel about development. We *do* want everyone's input and participation. The purpose of the core team is to be custodians of the project and to help manage its direction, not to have jealously-guarded control over it.

At some points in the past, django CMS tended to be led by a single person, especially in periods when others were less active, who sometimes thought up, implemented, reviewed and committed their own contributions to the codebase.

That worked well enough up to a certain point, but a year or so ago we realised that we needed to adopt a more formal and more collegiate way of working, to spread the decision-making and ensure that more people were aware of and agreed with any decisions.

Hence our regular core team meetings, attempts to expand the core team, new and explicit policies such as <http://docs.django-cms.org/en/develop/contributing/development.html#commit-policy-for-core-developers> and so on.

Anyway, we obviously need to do more to open the development process further, and to draw more people in.

>Is there some other
>forum I should be tracking if I want to participate or at least witness the
>discussion in real time? I don't expect to have final say, veto powers or
>commit rights, but having a voice would be nice. As it is, I feel that my
>only opportunity to contribute is to fix bugs in features that have already
>been decided on but rarely feel that I can chime in on whether the feature
>should exist or not.

Please do chime in, offer suggestions, make proposals. There's no other forum - just the email list, IRC, and GitHub.

I will try to encourage the other core developers to spend more time on the IRC channel, just so that they are there and are available, even if just to say hello now and then.

Maybe we can do more as well, but in the meantime just be assured it does matter and we will try various things to improve this. We won't ignore any suggestions.

Daniele

[John-Scott]

Hi Daniele,

Thanks for your thoughtful reply. At the outset, want to make clear that I do very much appreciate everyone's work on this project. There have been significant improvements in the last half year especially on several fronts (improved documentation on how to contribute, clarified policies, a recent uptick in blog posts, etc). Everyone I've interacted with has been friendly and welcoming.

On the specific issue of extended Django 1.6 support in django-cms 3.2, Tim spent considerable effort upstream to help clarify and formalize the Django release/deprecation timeline to ease the pain of projects like django-cms. He seemed to do this in direct response to the conversation at the top of this thread from January regarding Django 1.6 support in django-cms 3.1. The core dev meeting notes do not indicate whether the new upstream policies were factored in at all or not in the decision. Despite all of Tim's efforts, it appears he was first made aware of this extended 1.6 support in a side comment on ticket #3706, which probably did not feel like a reward for his efforts. The issue of whether to extend 1.6 support even further beyond 3.1 probably should have been discussed beforehand in this very thread.

Additionally, I'm not aware of what, if any, decisions have been made regarding the support policy for Divio hosted plugins. They seem to still be in a state of disarray regarding which versions of Django/django-cms they work with, have inconsistent versioning, etc. Some still do not even have Django 1.7+ migrations available (djangocms-table comes to mind), others have Django 1.7+ migrations in non-standard locations, etc. Fully realize it's mostly a volunteer effort to update these plugins but as a contributor, it would be great to have a clear policy so I know where to focus my own efforts.

I'd suggest to tag the last Django 1.4 compatible versions of all plugins for the stragglers and adopt a formal policy that acknowledges and perhaps even follows the upstream policies going forward. The N+1 releases could/should lose all Python 2.6/Django < 1.7 debt and have proper 1.7 & 1.8 support. I'd be happy to help with modernizing, even on plugins I do not directly use. However, I'm very unmotivated to also have to create temporary South migrations or add workarounds that are only required by unsupported versions of Django (1.4 is a few months away from extinction, all else < 1.7 is already extinct).

In general, any reason not to follow Django's lead on much if not everything regarding community/project management? I don't have an opinion on whether we need the overhead of a formal PEP/DEP-like process but at the very least any proposed feature or design decision ought to be mentioned on the developers mailing list so the community can provide feedback in advance. The core devs can continue to be custodians but would be great to have an opportunity to voice praise/concerns before they commit to a decision that affects the broader community (users, contributors, agencies, etc).

Thanks,

John-Scott

[Daniele Procida]

On Sat, Jul 25, 2015, John-Scott <john.scot...@gmail.com> wrote:

> The issue of whether to extend 1.6 support even
>further beyond 3.1 probably should have been discussed beforehand in this
>very thread.

I was some way through writing a longer reply to this when I had a kernel panic and lost it all.

Anyway, yes, we are going to make an effort to make sure that as much of the discussion and decision-making is open to everyone who has a stake in it in future.

>Additionally, I'm not aware of what, if any, decisions have been made
>regarding the support policy for Divio hosted plugins. They seem to still
>be in a state of disarray

Do you mean the ones on GitHub? Yes, you're right, it's rather a muddle, and also another thing we plan to address.

Anyone can help with this of course; if you know that one has some requirement that isn't clearly listed, send in a pull request to update its Readme (and mention it here perhaps).

We are also starting to add more django CMS applications to <http://django-cms.org/addons>, which will be better curated than the old add-ons pages, and allows developers to maintain up-to-date information about their django CMS software.

We'll get there bit-by-bit.

>In general, any reason not to follow Django's lead on much if not
>everything regarding community/project management? I don't have an opinion
>on whether we need the overhead of a formal PEP/DEP-like process but at the
>very least any proposed feature or design decision ought to be mentioned on
>the developers mailing list so the community can provide feedback in
>advance. The core devs can continue to be custodians but would be great to
>have an opportunity to voice praise/concerns before they commit to a
>decision that affects the broader community (users, contributors, agencies,
>etc).

I agree. This does happen to an extent in GitHub conversations, but even I find it hard to keep up with those.

We don't have the volunteers to implement much in the way of formal processes, but we can certainly make many improvements without going all that way.

Daniele

[Tim Graham]

Are your projects stuck on Python 2.6 too? If not, you could at least drop support there to allow reducing some tech debt (and introducing more).

I still feel the "an easier upgrade path" argument is very hand-wavy and not really explaining the entire story. I don't care so much about the current decision as it seems there no changing now, but rather how we might be able to avoid a situation like this in the future.

[Daniele Procida]

On Fri, Aug 7, 2015, Tim Graham <timog...@gmail.com> wrote:

>Are your projects stuck on Python 2.6 too?

Pass. Maybe someone else can answer that.

>I still feel the "an easier upgrade path" argument is very hand-wavy and
>not really explaining the entire story.

Indeed not, it was only one reason. But as I said before, if a project needs to be updated to work with newer software, it's easier to do this if you have more choice about which order you do all that work in (not to mention more time), rather than being constrained by a change that drops support for something.

It might not be the best reason, but it is a reason.

> I don't care so much about the
>current decision as it seems there no changing now, but rather how we might
>be able to avoid a situation like this in the future.

If someone had pointed out there was no mention of Django version support in the release plan before the release we could at least have had a discussion of the question, so we want that sort of thing to be easier for people to notice next time round.

I think that the discussion we've had about this will help, because it's been a reminder about being clearer and the importance of communicating better. We all agree that we need to hear the input of the community before making decisions, whatever the decision is in the end.

Daniele

[Tim Graham]

I saw some good news in the 3.2 release notes: "In django CMS 3.3: Django 1.6 and Python 2.6 will no longer be supported."

In my opinion, it would also be appropriate for 3.2 to be the last version to support Django 1.7 since support ends December 1 upon the release of Django 1.9. Thoughts?

[Iacopo Spalletti]

Il 09/11/2015 20:37, Tim Graham ha scritto:
> I saw some good news in the 3.2 release notes: "In django CMS 3.3:
> Django 1.6 and Python 2.6 will no longer be supported."
>
>
> In my opinion, it would also be appropriate for 3.2 to be the last
> version to support Django 1.7 since support ends December 1 upon the
> release of Django 1.9. Thoughts?

I'm +1 on this. I see little value in 1.7 support anyway.

>
> On Friday, August 7, 2015 at 11:59:04 AM UTC-4, Daniele Procida wrote:
>

> On Fri, Aug 7, 2015, Tim Graham <timog...@gmail.com <javascript:>>

> --
> Message URL:
> https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id
> Unsubscribe: send a message to
> django-cms-devel...@googlegroups.com
> ---

> You received this message because you are subscribed to the Google
> Groups "django CMS developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-cms-devel...@googlegroups.com
> <mailto:django-cms-devel...@googlegroups.com>.

> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/django-cms-developers/dbf11816-b047-423e-959f-4acc8a93d3d4%40googlegroups.com
> <https://groups.google.com/d/msgid/django-cms-developers/dbf11816-b047-423e-959f-4acc8a93d3d4%40googlegroups.com?utm_medium=email&utm_source=footer>.

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


--

Saluti

Iacopo Spalletti

[Martin Koistinen]

Also +1.