Re: URL namespaces

[Aymeric Augustin]

2015-06-12 0:38 GMT+02:00 Marten Kenbeek :

> The change causes exactly... 1 test failure,
> `shortcuts.tests.ShortcutTests.test_render`. It's not even a functional
> test, it only fails because
> `self.assertFalse(hasattr(response.context.request, 'current_app'))`
> fails.The template tests don't even have any namespaced urls, so
> `request.current_app` is pretty much untested.
>

Some of these tests may not be up to modern standards of writing good tests.

At least that's what I remember from refactoring them when I turned the
template engine into a library.

Sometimes git blame helps find the original author's intentions and improve
the tests.

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/CANE-7mXhLMCkd5WH%2BSD3Lo6HOW9w8UGUhquc7cJrn6KpVntjFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: MigrationTestCase

[Sean Briceland]

I believe Tom is referring to testing their migration files in order to 
ensure DB is migrated accordingly.

For example, at our company we test all of our source code & Migrations are 
code too! Most of the time we test rolling migrations forwards and 
backwards to ensure they will run without a hitch once deployed to 
production. 

For data migrations we use the MigrationLoader to generate models at a 
given state of the migration history. Then we can verify we our code within 
the migration mutates the data as desired.

While Django Migrations are tested, stable, & kicka$$, they do not prevent 
developers from generating erroneous data migrations or even irreversible 
schema migrations.

I jumped on this post because we now have a pretty beefy Django Application 
and as a result our Migration Tests take forever. Without getting into to 
much detail, I want to make sure that it would be okay to post here? or 
should I open a new thread?

On Friday, May 8, 2015 at 12:36:48 PM UTC-4, Andrew Godwin wrote:
>
> Hi Tom,
>
> When you say "testing migrations", what do you mean exactly? The migration 
> framework itself is heavily unit-tested, so I presume you intend to test 
> things like custom RunPython function bodies and the like?
>
> Andrew
>
> On Thu, May 7, 2015 at 3:30 AM, Tom Linford  > wrote:
>
>> At Robinhood, we've been using a custom in-house MigrationTestCase for 
>> testing migrations that we'd like to contribute, but want to check the API 
>> of it before contributing it. Here's the definition of the class:
>>
>> class MigrationTestCase(TransactionTestCase):
>> """
>> app_label: name of app (ie. "users" or "polls")
>> (start|dest)_migration_name: name of migration in app
>> (e.g. "0001_initial")
>> additional_dependencies: list of tuples of `(app_label, 
>> migration_name)`.
>> Add any additional migrations here that need to be included in the
>> generation of the model states.
>>
>> Usage:
>>
>> class TestCase(MigrationTestCase):
>> app_label = ...
>> start_migration_name = ...
>> dest_migration_name = ...
>> additional_dependencies = ...
>>
>> def setUp(self):
>> # Create models with regular orm
>> super(TestCase, self).setUp()
>> # Create models with start orm. Access model with:
>> # self.start_models[""][""]
>> # Note that model_name must be all lower case, you can just 
>> do:
>> # ._meta.model_name to get the model_name
>>
>> def test(self):
>> # Still using start orm
>> self.migrate_to_dest()
>> # Now, you can access dest models with:
>> # self.dest_models[""][""]
>> """
>> app_label = None
>> start_migration_name = None
>> dest_migration_name = None
>> additional_dependencies = []
>>
>>
>> Let me know if this API is agreeable and I can make a PR for this feature.
>>
>> -- 
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/8818bf72-aa66-4351-9177-e6e0f6605386%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/74578134-3314-4715-ba94-b63da47c5dd1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: MigrationTestCase

[Tim Graham]

Sure... what do you think of the API that Tom proposed? Did you have 
something different in mind?

On Friday, June 12, 2015 at 10:23:57 AM UTC-4, Sean Briceland wrote:
>
> I believe Tom is referring to testing their migration files in order to 
> ensure DB is migrated accordingly.
>
> For example, at our company we test all of our source code & Migrations 
> are code too! Most of the time we test rolling migrations forwards and 
> backwards to ensure they will run without a hitch once deployed to 
> production. 
>
> For data migrations we use the MigrationLoader to generate models at a 
> given state of the migration history. Then we can verify we our code within 
> the migration mutates the data as desired.
>
> While Django Migrations are tested, stable, & kicka$$, they do not prevent 
> developers from generating erroneous data migrations or even irreversible 
> schema migrations.
>
> I jumped on this post because we now have a pretty beefy Django 
> Application and as a result our Migration Tests take forever. Without 
> getting into to much detail, I want to make sure that it would be okay to 
> post here? or should I open a new thread?
>
> On Friday, May 8, 2015 at 12:36:48 PM UTC-4, Andrew Godwin wrote:
>>
>> Hi Tom,
>>
>> When you say "testing migrations", what do you mean exactly? The 
>> migration framework itself is heavily unit-tested, so I presume you intend 
>> to test things like custom RunPython function bodies and the like?
>>
>> Andrew
>>
>> On Thu, May 7, 2015 at 3:30 AM, Tom Linford  wrote:
>>
>>> At Robinhood, we've been using a custom in-house MigrationTestCase for 
>>> testing migrations that we'd like to contribute, but want to check the API 
>>> of it before contributing it. Here's the definition of the class:
>>>
>>> class MigrationTestCase(TransactionTestCase):
>>> """
>>> app_label: name of app (ie. "users" or "polls")
>>> (start|dest)_migration_name: name of migration in app
>>> (e.g. "0001_initial")
>>> additional_dependencies: list of tuples of `(app_label, 
>>> migration_name)`.
>>> Add any additional migrations here that need to be included in 
>>> the
>>> generation of the model states.
>>>
>>> Usage:
>>>
>>> class TestCase(MigrationTestCase):
>>> app_label = ...
>>> start_migration_name = ...
>>> dest_migration_name = ...
>>> additional_dependencies = ...
>>>
>>> def setUp(self):
>>> # Create models with regular orm
>>> super(TestCase, self).setUp()
>>> # Create models with start orm. Access model with:
>>> # self.start_models[""][""]
>>> # Note that model_name must be all lower case, you can just 
>>> do:
>>> # ._meta.model_name to get the model_name
>>>
>>> def test(self):
>>> # Still using start orm
>>> self.migrate_to_dest()
>>> # Now, you can access dest models with:
>>> # self.dest_models[""][""]
>>> """
>>> app_label = None
>>> start_migration_name = None
>>> dest_migration_name = None
>>> additional_dependencies = []
>>>
>>>
>>> Let me know if this API is agreeable and I can make a PR for this 
>>> feature.
>>>
>>> -- 
>>> 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 http://groups.google.com/group/django-developers.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/8818bf72-aa66-4351-9177-e6e0f6605386%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/e4aadb20-30ec-4968-8564-c6652dafeaf9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: MigrationTestCase

[Sean Briceland]

Let me run it by my CTO. But I should be able to send over our migration
test class.
On Jun 12, 2015 11:58 AM, "Tim Graham"  wrote:

> Sure... what do you think of the API that Tom proposed? Did you have
> something different in mind?
>
> On Friday, June 12, 2015 at 10:23:57 AM UTC-4, Sean Briceland wrote:
>>
>> I believe Tom is referring to testing their migration files in order to
>> ensure DB is migrated accordingly.
>>
>> For example, at our company we test all of our source code & Migrations
>> are code too! Most of the time we test rolling migrations forwards and
>> backwards to ensure they will run without a hitch once deployed to
>> production.
>>
>> For data migrations we use the MigrationLoader to generate models at a
>> given state of the migration history. Then we can verify we our code within
>> the migration mutates the data as desired.
>>
>> While Django Migrations are tested, stable, & kicka$$, they do not
>> prevent developers from generating erroneous data migrations or even
>> irreversible schema migrations.
>>
>> I jumped on this post because we now have a pretty beefy Django
>> Application and as a result our Migration Tests take forever. Without
>> getting into to much detail, I want to make sure that it would be okay to
>> post here? or should I open a new thread?
>>
>> On Friday, May 8, 2015 at 12:36:48 PM UTC-4, Andrew Godwin wrote:
>>>
>>> Hi Tom,
>>>
>>> When you say "testing migrations", what do you mean exactly? The
>>> migration framework itself is heavily unit-tested, so I presume you intend
>>> to test things like custom RunPython function bodies and the like?
>>>
>>> Andrew
>>>
>>> On Thu, May 7, 2015 at 3:30 AM, Tom Linford  wrote:
>>>
 At Robinhood, we've been using a custom in-house MigrationTestCase for
 testing migrations that we'd like to contribute, but want to check the API
 of it before contributing it. Here's the definition of the class:

 class MigrationTestCase(TransactionTestCase):
 """
 app_label: name of app (ie. "users" or "polls")
 (start|dest)_migration_name: name of migration in app
 (e.g. "0001_initial")
 additional_dependencies: list of tuples of `(app_label,
 migration_name)`.
 Add any additional migrations here that need to be included in
 the
 generation of the model states.

 Usage:

 class TestCase(MigrationTestCase):
 app_label = ...
 start_migration_name = ...
 dest_migration_name = ...
 additional_dependencies = ...

 def setUp(self):
 # Create models with regular orm
 super(TestCase, self).setUp()
 # Create models with start orm. Access model with:
 # self.start_models[""][""]
 # Note that model_name must be all lower case, you can just
 do:
 # ._meta.model_name to get the model_name

 def test(self):
 # Still using start orm
 self.migrate_to_dest()
 # Now, you can access dest models with:
 # self.dest_models[""][""]
 """
 app_label = None
 start_migration_name = None
 dest_migration_name = None
 additional_dependencies = []


 Let me know if this API is agreeable and I can make a PR for this
 feature.

 --
 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 http://groups.google.com/group/django-developers.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/django-developers/8818bf72-aa66-4351-9177-e6e0f6605386%40googlegroups.com
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/181BkMhFUwo/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@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/e4aadb20-30ec-4968-8564-c6652dafeaf9%40googlegroups.com
> 

Re: 1.9 release planning

[Carl Meyer]

Hi Matt,

On 06/11/2015 07:30 PM, Matt Austin wrote:
> On 11 June 2015 at 01:37, Collin Anderson  wrote:
>>
>> I'd propose something slightly different, that's very close to our current
>> deprecation timeline:
>> 1.8 (LTS): No features dropped.
>> 1.9: Dropped features deprecated in 1.5, 1.6, 1.7
>> 2.0: Dropped features deprecated in 1.8
>> 2.1 (LTS): No features dropped.
>> 2.2: Dropped features deprecated in 1.9, 2.0
>> 2.3: Dropped features deprecated in 2.1
>>
>> Seems to me features deprecated in an LTS are fair game to disappear in the
>> next LTS. This allows us to remove "dotted paths in reverse() and url()"
>> because that's deprecated in 1.8.
>>
>> If we can guarantee compatibility between LTSs, I think that would be a huge
>> win, at the cost of extending the removal of some deprecated features by one
>> release (8 months).
>>
> 
> Hi everyone,
> 
> Sorry to stick my nose in, but thought I might throw a potential
> spanner-in-the works with this release discussion, in regard to
> version naming.
> 
> I understand that the current version system doesn't have too much
> inherent meaning, and that 2.0 will come after 1.9 'just so we don't
> stay on 1.x forever'.
> 
> With a more structured release plan, and LTS releases, would it be
> worth considering LTS releases as 'major' version numbers, with
> regular releases and 'minor' version releases? It would be easier to
> identify LTS releases at a glance, and might provide more meaning to
> the versioning scheme?

I find this idea tempting too, but (as Collin indirectly pointed out)
the problem is that it flips semver on its head, which some people might
find surprising. Because in Collin's schedule it's the _LTS_ releases
where no APIs will be removed, whereas any non-LTS release might have
APIs removed.

Donald proposed in IRC that we could go with a standard
major/minor/bugfix semver approach, with the added guarantee that every
removed feature will be deprecated in one major release first (to
preserve the ability to straddle two major releases, or upgrade
major->major without hitting removed APIs). This is nice and simple and
conforms to semver, but it means that deprecated features would hang
around quite a bit longer.

Just for the sake of comparison and devils advocate, here's what a full
switch to semver could look like for Django (I'll hand-wave past the
transition and just start with a hypothetical 2.0 release, which is
major/"LTS"):

2.0 - 0 mos - "LTS"
2.1 - 8 mos - may add/deprecate features, but not remove
2.2 - 16 mos - may add/deprecate features, but not remove
3.0 - 24 mos - "LTS" - remove any features already deprecated in 2.0
3.1 - 32 mos - may add/deprecate features, but not remove
3.2 - 40 mos - may add/deprecate features, but not remove
4.0 - 48 mos - "LTS" - removes features deprecated in 2.1, 2.2, or 3.0
... etc ...

Just like in the current proposal, 2.0 would continue to receive 2.0.X
security releases until a year after 3.0 is released (thus for three
years, given no delays). 2.1 would receive bugfix releases until 2.2 is
released, and thereafter security releases until 3.0 is released. 2.2
would receive security releases until 3.1 is released. (This is just
like the current system.)

This scheme conforms to semver, and allows for no-breakage
straddling/upgrades from major(LTS) to major(LTS) release. The cost,
compared to the current proposal, is that a deprecated feature might
need to stick around _in master_ for almost four years (if it's
deprecated in e.g. 2.1 and then finally removed in 4.0). Whereas in
Collin's proposal, the longest a deprecated feature would ever stay in
master is about two years (e.g. from 1.9 to 2.1 in his schedule above).

I'll admit that the simplicity (and semantic version numbering) of this
scheme does grow on me, but I don't get the feeling that the core team
is really ready to accept that length of continued support for
deprecated APIs.

Carl

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/557B0FA6.1010605%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: 1.9 release planning

[Aymeric Augustin]

2015-06-12 18:58 GMT+02:00 Carl Meyer :

> I don't get the feeling that the core team is really ready to accept
>
that length of continued support for deprecated APIs.
>

Especially if the deprecation and removal is a pre-requisite for
implementing a new feature... I'm not writing code that I can't use
until 2020!

-- 
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/CANE-7mXTzJrVHy2wmN3ssxecUPYqxs5DN_CvOzDb%3D7DjirNw3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: MigrationTestCase

[Sean Briceland]

I like Tom's initial proposition. As mentioned ours is very similar. Here 
is currently what we are using:

class MigrationTestBase(TransactionTestCase):
"""
Custom TestCase containing an extended set of asserts for testing
migrations and schema operations.
Most of this code was derived from Django's private MigrationTestBase:

https://github.com/django/django/blob/stable/1.7.x/tests/migrations/test_base.py

Notes:
If you would like to override setUp() in the test, you will want to
call super().setup() or explicitly invoke 
self.migrate_all_the_way() to
ensure a clean history at the start of each test.
"""

# MUST specify which apps we will need to test within the
app_label = None
test_migration_name = None

# last_migration_nodes is a list of tuples assigned after each time we
# migrate.
# if last_migration_node is None, we will use apps from django.apps 
which
# is the fully migrated App Registry created via our existing source 
code.
last_migration_nodes = None

@classmethod
def setUpClass(cls):
super(MigrationTestBase, cls).setUpClass()
if not cls.app_label or not cls.test_migration_name:
raise NotImplementedError('Must define class defaults: 
app_label, '
  'test_migration_name')

def setUp(self):
super(MigrationTestBase, self).setUp()
self.migrate_all_the_way()

def tearDown(self):
self.migrate_all_the_way()
super(MigrationTestBase, self).tearDown()

def migrate_to(self, app_label, migration_name):
call_command('migrate', app_label, migration_name, verbosity=0)
self.last_migration_nodes = [(app_label, migration_name)]

def migrate_to_test_migration(self):
self.migrate_to(self.app_label, self.test_migration_name)

def migrate_all_the_way(self):
call_command('migrate', verbosity=0)
self.last_migration_nodes = None

def get_current_model(self, app_label, model):
if self.last_migration_nodes is not None:
conn = connections[DEFAULT_DB_ALIAS]
loader = MigrationLoader(conn)
proj_state = loader.project_state(self.last_migration_nodes)
self.apps = proj_state.render()
return self.apps.get_model(app_label, model)
return dj_apps.get_model(app_label, model)

def get_table_description(self, table):
with connection.cursor() as cursor:
return connection.introspection.get_table_description(
cursor, table
)

def assertTableExists(self, table):
with connection.cursor() as cursor:
self.assertIn(
table,
connection.introspection.get_table_list(cursor)
)

def assertTableNotExists(self, table):
with connection.cursor() as cursor:
self.assertNotIn(
table,
connection.introspection.get_table_list(cursor)
)

def assertColumnExists(self, table, column):
self.assertIn(
column,
[c.name for c in self.get_table_description(table)]
)

def assertColumnNotExists(self, table, column):
self.assertNotIn(
column,
[c.name for c in self.get_table_description(table)]
)

def assertColumnNull(self, table, column):
self.assertEqual(
[
c.null_ok
for c in self.get_table_description(table) if c.name == 
column
][0],
True
)

def assertColumnNotNull(self, table, column):
self.assertEqual(
[
c.null_ok
for c in self.get_table_description(table)
if c.name == column
][0],
False
)

def assertIndexExists(self, table, columns, value=True):
with connection.cursor() as cursor:
self.assertEqual(
value,
any(
c["index"]
for c in connection.introspection.get_constraints(
cursor, table).values()
if c['columns'] == list(columns)
),
)

def assertIndexNotExists(self, table, columns):
return self.assertIndexExists(table, columns, False)

def assertFKExists(self, table, columns, to, value=True):
with connection.cursor() as cursor:
self.assertEqual(
value,
any(
c["foreign_key"] == to
for c in connection.introspection.get_constraints(
cursor, table).values()
if c['columns'] == list(columns)
),
)

def assertFKNotExists(self, table, columns, to, value=True):
return self.assertFKExists(table, columns, to, False)



-- 
You received this mes

Re: 1.9 release planning

[Ryan Hiebert]

An alternative would be for the LTS to be the second-to-last minor release 
before a major version bump.

I'm also ignoring the transition for the sake of hypotheticals. I'm also 
assuming that 2.2 is the last release of the 2.X series.

2.1 - 0 mos - (LTS) No features dropped
2.2 - 8 mos - No features dropped
3.0 - 16 mos - Drop all features deprecated by 2.1
3.1 - 24 mos - (LTS) No features dropped
3.2 - 32 mos - No features dropped
4.0 - 40 mos - Drop all features deprecated by 3.1
4.1 - 48 mos - (LTS) No features dropped 

It would mean that features deprecated before an LTS cannot be dropped until 
two versions after the LTS, but it fits semver pretty well, and doesn't speed 
up our deprecation removal.

I'd argue for a major version dropping _all_ deprecated features. This has the 
downside of speeding up our removal process in the last version of a major 
release, and it encourages people to stay longer on the release previous, since 
they won't have as much opportunity to fix them. It would also mean that 
features deprecated in the last minor version of a major version line would 
need to skip the pending deprecation warnings.

If it were acceptable to do that, then I'd argue for the LTS to be the _last_ 
in a major version line, rather than the second-to-last. That would probably be 
my overall preferred, though I do recognize the previously mentioned drawbacks. 
Anything deprecated in an LTS in that case would skip the pending deprecation 
warning, and go straight to the deprecation warning. The deprecation timeline 
would then look like this:

2.2 - 0 mos - (LTS) No features dropped
3.0 - 8 mos - All deprecations, including the LTS deprecations, are removed
3.1 - 16 mos - No features dropped
3.2 - 24 mos - (LTS) No features dropped
4.0 - 32 mos - All deprecations, including the LTS deprecations, are removed
4.1 - 40 mos - No features dropped
4.2 - 48 mos - (LTS) No features dropped


I think those are probably the two best LTS support release schedules that 
follow semver.

Ryan

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/F36EA2A5-4D9F-489C-82B9-7AE4D93B258F%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Tim Graham]

I'm still in favor of "Collin's proposal." You'll need to convince me that 
keeping deprecations around longer is worth having somewhat meaningful 
version numbers, but I'm not sure I really consider dropping deprecation 
shims as "incompatible API changes" that justify a major version bump. For 
example, if I run on 2.X (whatever is right before the version where 
features are dropped) without deprecation warnings, then upgrading to 3.0 
isn't any more difficult than other upgrades. It might be a nice touch to 
call the version after the next LTS (2.1 under Collin's proposal) "3.0" 
since it will drop Python 2 support, but it's not really important IMO

On Friday, June 12, 2015 at 8:00:30 PM UTC-4, Ryan Hiebert wrote:
>
> An alternative would be for the LTS to be the second-to-last minor release 
> before a major version bump. 
>
> I'm also ignoring the transition for the sake of hypotheticals. I'm also 
> assuming that 2.2 is the last release of the 2.X series. 
>
> 2.1 - 0 mos - (LTS) No features dropped 
> 2.2 - 8 mos - No features dropped 
> 3.0 - 16 mos - Drop all features deprecated by 2.1 
> 3.1 - 24 mos - (LTS) No features dropped 
> 3.2 - 32 mos - No features dropped 
> 4.0 - 40 mos - Drop all features deprecated by 3.1 
> 4.1 - 48 mos - (LTS) No features dropped 
>
> It would mean that features deprecated before an LTS cannot be dropped 
> until two versions after the LTS, but it fits semver pretty well, and 
> doesn't speed up our deprecation removal. 
>
> I'd argue for a major version dropping _all_ deprecated features. This has 
> the downside of speeding up our removal process in the last version of a 
> major release, and it encourages people to stay longer on the release 
> previous, since they won't have as much opportunity to fix them. It would 
> also mean that features deprecated in the last minor version of a major 
> version line would need to skip the pending deprecation warnings. 
>
> If it were acceptable to do that, then I'd argue for the LTS to be the 
> _last_ in a major version line, rather than the second-to-last. That would 
> probably be my overall preferred, though I do recognize the previously 
> mentioned drawbacks. Anything deprecated in an LTS in that case would skip 
> the pending deprecation warning, and go straight to the deprecation 
> warning. The deprecation timeline would then look like this: 
>
> 2.2 - 0 mos - (LTS) No features dropped 
> 3.0 - 8 mos - All deprecations, including the LTS deprecations, are 
> removed 
> 3.1 - 16 mos - No features dropped 
> 3.2 - 24 mos - (LTS) No features dropped 
> 4.0 - 32 mos - All deprecations, including the LTS deprecations, are 
> removed 
> 4.1 - 40 mos - No features dropped 
> 4.2 - 48 mos - (LTS) No features dropped 
>
>
> I think those are probably the two best LTS support release schedules that 
> follow semver. 
>
> Ryan

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/f887421b-c470-491f-b5f0-a12af397bfe1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.