Re: 1.9 release planning

I like Colin's proposed schedule. Regards, Michael Manfre On Thu, Jun 11, 2015 at 1:12 AM, Anssi Kääriäinen wrote: > +1 to Collin's release schedule. > > This schedule should make it extremely easy to support "develop using > latest release, maintain using latest LTS". With

Re: Feature: Template Components

On Wednesday, 10 June 2015 02:55:46 UTC+2, Curtis Maloney wrote: > > This sounds a bit like combining django-sniplates with django-amn, and > going a bit further... > > Fragments of templates, list of JS/CSS dependencies, and a way to collect > it all together and ensure your page has everything

Re: URL namespaces

About #24127, I'd like if you could investigate if making the backwards incompatible change breaks any tests in Django's test suite. That would offer a starting point to think about the ramifications. Wouldn't the fix for broken user code be to set "request.current_app = None" where necessary?

Re: App config on the default template for app creation

Aymeric, did you consider it? It seems reasonable to me. On Friday, June 5, 2015 at 9:35:37 AM UTC-4, Mounir Messelmeni wrote: > > Will it be better to add apps.py and app_config on the __init__.py file > when we run ./manage.py startapp? > I think this way users will know more about this

Re: Feature: URL template tag, optional parameters

I think you'll have to try implementing it to see if it's feasible. On Thursday, June 4, 2015 at 5:44:54 AM UTC-4, erez@gmail.com wrote: > > Hi, > > AFAIK, the recommended way in Django to handle multiple urls with the same > view, is to have optional parameters. ( >

Re: Introducing django-compat - arteria's solution for for- and backwards compatibility from Django 1.4.x to 1.8.x/1.9.x

Just in case followers of this thread didn't see it, Collin proposed a new schedule in the "1.9 release planning thread" that I believe solves these concerns and doesn't delay deprecation removals as much as the schedule proposed by Loic. Please take a look and continue the discussion there.

Re: App config on the default template for app creation

> On 11 juin 2015, at 21:04, Tim Graham wrote: > > Aymeric, did you consider it? No, I didn’t. > It seems reasonable to me. Yes, it is. My extreme dislike of code generation extends to startapp but I’ve created enough apps.py files to accept the practicality of this

Re: URL namespaces

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

Re: App config on the default template for app creation

Thanks, I added a ticket: https://code.djangoproject.com/ticket/24971 On Thursday, June 11, 2015 at 4:52:46 PM UTC-4, Aymeric Augustin wrote: > > > On 11 juin 2015, at 21:04, Tim Graham > wrote: > > > > Aymeric, did you consider it? > > No, I didn’t. > > > It seems

Re: 1.9 release planning

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

Re: 1.9 release planning

Hi Matt, I was thinking about this too and it came up on IRC today. I think if we were to strictly go with something like semver, we'd end up with a numbering scheme like 2.0, 2.1 (LTS), 3.0, 4.0, 4.1 (LTS), 5.0, etc, because features can be removed in between LTSs (assuming they're marked as