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
e
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 feat
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 der
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
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
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 Bricelan
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,
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 h
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
