On 7/10/14 6:32 AM, Stan wrote:
I tried to found a revision in the /stable/1.7.x/ branch showing a
regression in the time needed to run the test suite with Coverage.
Unfortunately I was unable to find such commit because with checkouts
from the 12 of june and beyond, my test starts to break.
C
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
On Monday, July 14, 2014 9:50:53 PM UTC+2, Aymeric Augustin wrote:
> [snip]
+1, please leave it there
--
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 djang
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
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 depre
> 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 writt
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 Ch
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 y
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 s
