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
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 fe
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 reasonable to me.
>
> Ye
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.curren
> 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 suggestion.
--
Aymeric.
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.
Th
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. (
> https://docs.djangoproje
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 feature
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?
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
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 the above schedule i
11 matches
Mail list logo
