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
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
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,
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
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
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
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
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'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
