🧺 Add support for Django2.2, drop support for Django2.0 #133
Conversation
dodobas
force-pushed
the
bump_django_version
branch
from
4766ffc
to
aad910e
Compare
dodobas
changed the title
dodobas
force-pushed
the
bump_django_version
branch
from
aad910e
to
3696999
Compare
README.md
Outdated
| @@ -22,7 +22,7 @@ Smartmin tries to stay in lock step with the latest Django versions. With each n | |||
| will be released and we will save the major changes (possibly breaking backwards compatibility) on these versions. This | |||
| includes updating to the latest version of Twitter Bootstrap. | |||
|
|
|||
| The latest version is the 2.1.* series which works against Django 1.11, 2.0 and 2.1. | |||
| The latest version is the 2.2.* series which works against Django 1.11, 2.1 and 2.2. | |||
There was a problem hiding this comment.
shouldn't we be supporting 2.0, 2.1 and 2.2? We've always supported last 3 versions
There was a problem hiding this comment.
I think keeping 1.11 which is LTS and the only that support Python 2 is a good thing for now
There was a problem hiding this comment.
that is correct, the other major reason is the fact that Django2.0 extended support has ended in April, 2019
There was a problem hiding this comment.
@norkans7 we've already ripped out Python 2 support in smartmin
Our contract here has always been to support the last 3 major versions of Django regardless of what's LTS and not. If we're going to change that now we should decide what the new contract is so we don't have the discussion every time a new Django version comes out. Is it last two LTS versions but not the non-LTS versions in between?
Personally I don't see a strong argument to change from what we've down in the past and I like the idea of cleaning out any remaining Django 1.x compatibility stuff.
There was a problem hiding this comment.
Definitely don't need to support python2.
I don't think we want last three major versions, at least not in the semantic versioning meaning of that. Last 3 minor versions?
Looking at:
https://www.djangoproject.com/download/
Their LTS promises are pretty big, like 3 years after release for extended support. That seems like a bigger promise than we really want to make.
Maybe we say we support the latest major mainstream supported versions?
That would currently put us as supporting 2.2.* since support for 2.1.* ended in April?
We probably don't want to super overthink it but at least that would be a guideline?
There was a problem hiding this comment.
Though looking at their schedule maybe that doesn't work because they don't seem to overlap mainstream support at all. (which is weird)
So ya, let's just say last two release series, simpler anyways.
There was a problem hiding this comment.
So right now 2.2.* and 2.1.* .. in December will be 3.0.* and 2.2.*
There was a problem hiding this comment.
I'm fine with that, though in practice, won't that we just be the latest 2.1 and latest 2.2 patch releases? Just thinking in terms of what we CI test with.
There was a problem hiding this comment.
(and in theory it's only bug fixes between 2.2.x and 2.2.y so no reason to not be on the latter)
There was a problem hiding this comment.
In theory patch releases should have no changes in functionality, so really doesn't matter. I think it is clear if we say 2.1.* and 2.2.* and that should cause us no burden.
No description provided.