use semantic versioning after 2.0?

[Collin Anderson]

Hi All,

I just saw #23015 come through (1.9 -> 2.0 not an earth-shattering release). I think it's a little ridiculous that decimal point doesn't really mean anything.

I'm wondering if it would make sense, after 2.0, to follow Chrome, Firefox, and semantic versioning (http://semver.org/), and simply go with 3.0, 4.0, etc. in the future. The Patch/Micro versions would be 2.0.2, 3.0.1, etc. There would never be a 2.1.0 unless we somehow had nothing to remove on the deprecation timeline, which has never happened before.

It means we would always have an extra zero in the version instead of a meaningless decimal point, but it makes more sense to me at least.

Or am I just crazy?

Thanks,

Collin

[Greg Chapple]

I'm not overly familiar with how Django versions are decided, but from what I know about semver, the example you give is not quite correct.

From the semver website:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

---

If this was to be followed then we would not be left with the extra zero as you mention, which to me seems just a bit redundant.

I'm all for using semver, though! So +1 on the suggestion.

Greg

--
You received this message because you are subscribed to the Google Groups "Django developers" 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/747d4275-6562-4981-b6d4-2c56237d5876%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Shai Berger]

On Monday 14 July 2014 20:07:16 Collin Anderson wrote:
> Hi All,
>
> I just saw #23015 come through (1.9 -> 2.0 not an earth-shattering
> release). I think it's a little ridiculous that decimal point doesn't
> really mean anything.
>
> I'm wondering if it would make sense, after 2.0, to follow Chrome, Firefox,
> and semantic versioning (http://semver.org/), and simply go with 3.0, 4.0,
> etc. in the future. The Patch/Micro versions would be 2.0.2, 3.0.1, etc.
> There would never be a 2.1.0 unless we somehow had nothing to remove on the
> deprecation timeline, which has never happened before.
>

FWIW, I always thought the version after 1.9, if it isn't earth-shattering,
should be 1.10. Reasons to break things will pop up in due time (e.g. the
death of python 2 in 2019).

Shai.

[Collin Anderson]

> MAJOR version when you make incompatible API changes,MINOR version when you add functionality in a backwards-compatible manner

Although our changes are backwards compatible, they are only guaranteed to be backwards compatible for the previous two versions. Instead, semver says that code written for django 1.1 should run just fine on django 1.6.

> if it isn't earth-shattering, should be 1.10. Reasons to break things will pop up in due time (e.g. the death of python 2 in 2019). 

I'm also ok with django 1.10, though I also like incrementing the major version regularly as a way of saying "we don't plan on making earth-shattering changes". In retrospect, I think it would have been better if python made the backwards-incompatible changes slowly, with warnings, over the course of several releases instead of all at once. If we do ever make earth-shattering changes, I think it would be smart to use a whole new module and package name such as django2. That way you can easily have both installed at the same time.

[Donald Stufft]

Semver doesn’t require that a MAJOR increment be earth shattering, just that it’s used

to mark backwards incompat changes. Realstically dropping the 1. would make sense

for Django + Semver since every 1.x version is potentially backwards incompat since it

tends to remove something that was deprecated.

--
You received this message because you are subscribed to the Google Groups "Django developers" 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/5fab23be-1411-4813-bfbe-ef85d0025452%40googlegroups.com.

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

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

[Aymeric Augustin]

Hello,

Version numbers are symbolic values with no inherent meaning. As a consequence, anyone may choose to follow any convention. You’re welcome to find 1.9 —> 2.0 ridiculous just as much as I’m welcome (or at least, I hope so) to find 1.9 —> 1.10 laughable ;-) Seriously, in the grand scheme of things, this doesn’t matter much.

Since we have a mechanism for backwards-incompatible changes, namely the two-release deprecation process, we believe that we’ll never have to pull a Python 3. In fact, we’d rather not, considering how it went. So, in order not to stay stuck at 1.xx forever, we — the core team — decided that the version after 1.9 would be 2.0.

When I say “we decided”, I mean that we had this discussion at a few DjangoCons, that most core devs found that option acceptable, and that it became tribal knowledge. No one took issue with the introduction of RemovedInDjango20Warning as the successor to RemovedInDjango19Warning.

Discussions about versioning schemes are about as religious as those about text editors, so, please, let’s leave it there. If one or several core devs — I see that Shai supports 1.10 — want to resume this holy war, let’s handle it at the scale of the core team, not at the scale of django-developers.

We’ll be fine anyway.

Thank you!

--
Aymeric.

[Florian Apolloner]

On Monday, July 14, 2014 9:50:53 PM UTC+2, Aymeric Augustin wrote:
> [snip]

+1, please leave it there

[Anders Steinlein]

Just want to throw in one point to consider here, pardon me if this has already been discussed in the core team.

Bumping the "major version", that is moving to 2.0 instead of 1.10, will from the outside likely be seen as a larger change, regardless of whether it technically is or not. This, could again give some PR boost -- if one is willing to seize the opportunities so to speak.

Just to pick one example, this is how PostgreSQL generally decides to handle bumps in major versions. 9.0 could've technically be 8.5 (it is no more backwards-incomatible than 8.3->8.4), but they decided to bump the major version to reap additional PR due to the large features introduced. In the same vein, I would've liked Django 1.7 with its major and awesome additions to have been 2.0, but I guess that opportunety has passed long ago. :)

Regards,

Anders

--

You received this message because you are subscribed to the Google Groups "Django developers" 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/2f72c74f-e48b-4f96-9ebd-00bb204e9a82%40googlegroups.com.