Re: 1.9 release planning

[Collin Anderson]

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 
deprecated in the previous LTS).

Collin

On Thursday, June 11, 2015 at 9:31:08 PM UTC-4, 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? 
>
> Feel free to shut this idea down if it's going to open a can-of-worms :) 
>
>
> Cheers, 
>
> -- 
> Matt 
>

-- 
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/43108c2b-e8f0-4d69-bb70-da3ac4c516ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Matt Austin]

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?

Feel free to shut this idea down if it's going to open a can-of-worms :)


Cheers,

--
Matt

-- 
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/CACATwqQge_4Bx%2BctJFsf02uTyhu9gy4GMBaUHx23XUEY6yXCuw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: App config on the default template for app creation

[Tim Graham]

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. 
>
> 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. 
>
>
>
>
>

-- 
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/c727a776-b380-4913-beb7-3238987f914d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: URL namespaces

[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. 

"request.current_app = None" would indeed fix any broken user code. 

Op donderdag 11 juni 2015 21:02:59 UTC+2 schreef Tim Graham:
>
> 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 Sunday, June 7, 2015 at 3:29:56 PM UTC-4, Marten Kenbeek wrote:
>>
>> So 2) has been fixed (#24904 and #24906), and I got a PR for 1) (
>> https://github.com/django/django/pull/4724). 
>>
>> About #24127: I see a few options here:
>>
>>
>>1. A context processor or similar that sets `current_app` if it isn't 
>>set. By default `current_app` doesn't exist, so there's a good 
>> distinction 
>>between not set and set to `None`. This would be 100% backwards 
>> compatible, 
>>but IMO it's not the best solution in the long term. 
>>2. Provide a new flag to {% url %} to reverse with current_app set to 
>>request.resolver_match.namespace. This feels slightly less awkward than 
>> the 
>>current method recommended by the docs.
>>3. Deprecating a non-existing current_app to force an explicit choice 
>>between the old and new behaviour, then add the new behaviour after the 
>>deprecation period. This would be coupled with option 1 for ease-of-use. 
>>4. A setting? A setting! Yay, another setting...
>>5. Document the slight backwards-incompatible change? And provide an 
>>easy way to retain the old behaviour, of course. 1 through 4 are all far 
>>from ideal, and I don't think there's an easy, backwards-compatible fix 
>>here. 
>>
>> Thoughts?
>>
>> Op dinsdag 2 juni 2015 14:32:42 UTC+2 schreef Marten Kenbeek:
>>>
>>> The admin proves problematic. Looking at the uses of `AdminSite.name`, 
>>> it's not easily replaced. There are quite a few places that use the name to 
>>> reverse urls, but don't have access to the request and the current 
>>> namespace. I think the best solution for now is to document that you should 
>>> pass `admin.site.urls` directly to `url()`. `include()` does a bunch of 
>>> stuff, but none of it is needed in the case of the admin urls. This allows 
>>> the new `include()` API to be as intended, but it doesn't put an 
>>> unnecessary burden of providing the "correct" namespace for an admin 
>>> instance on the end-developer. 
>>>
>>> In time I'd like to see a method on the AdminSite that returns an actual 
>>> resolver object, using the new API. The default URLconf template would 
>>> simply look something like this:
>>>
>>> urlpatterns = [
>>> admin.site.get_resolver('^admin/'),  # or 
>>> get_resolver(RegexPattern('^admin/')) to be more explicit
>>> ]
>>>
>>> This would solve the namespace issue for the admin, but it would still 
>>> allow for only obvious way to set the instance namespace, and keep the 
>>> `include()` API clean.
>>>
>>> Op zaterdag 30 mei 2015 14:28:22 UTC+2 schreef Tai Lee:

 Right. So if I understand correctly, you can avoid problems even when 
 installing two different apps into the same app namespace as long as you 
 *always* supply `current_app` when reversing URLs? In which case, I don't 
 think we need to worry about being able to change the app namespace to 
 avoid conflicts (maybe we should even disallow it), and instead just make 
 it easier to *always* supply `current_app`, which brings me to my next 
 point.

>>>
>>> Not providing an option in the API itself is the best we can do to 
>>> disallow it. But yes, always setting the current_app would avoid a lot of 
>>> problems. https://code.djangoproject.com/ticket/24127 proposes just 
>>> that. 
>>>
>>> I'd take this a step further. In this comment -- 
 https://code.djangoproject.com/ticket/21927#comment:9 
 
  
 -- I made a suggestion that Django set a `current_app` hint in thread 
 local 
 storage with a middleware class or even before middleware runs, and then 
 have `reverse()` and `{% url %}` fallback to that default hint ONLY if no 
 current app is explicitly provided via the current mechanisms, so it 
 should 
 be a relatively safe change.

 This should make it much more convenient and possible to reverse URLs 
 correctly regardless of conflicting app namespaces, even in code that 
 doesn't have access to the request object. For example, model methods 

Re: App config on the default template for app creation

[Aymeric Augustin]

> 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.




-- 
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/D455669E-A0B6-409A-B65F-C761A6383099%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

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

[Tim Graham]

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. 
Thanks!

On Wednesday, June 10, 2015 at 4:12:15 AM UTC-4, Philippe O. Wagner wrote:
>
> Hi all, 
> 
> I'd like to highlight these two points from the OP:
> 
> * Eliminate code duplication from app to app and handle them in one 
> central place.
> * Have a stable and testet single library that handles these 
> compatible objects ...
> 
> It's not only about the version to version support, but also to follow the 
> DRY principle and support other 3rd party apps. It follows the same idea 
> like six does for Python 2.x to Python 3.x compatibility. 
> 
> BTW, good point Loïc about "providing an upgrade path" and keep the 
> intermediate versions even not for production. We will keep this in mind 
> for django-compat.
> 
> Tim, from my point of view it's not the number, 25% in this case, that 
> matters. It depends who starts with the latest greatest version and who use 
> the LTS.  I think agencies with a lot of customer and big, complex projects 
> will/tend to build on a LTS version. These numbers depends totally who 
> answers the survey.
>
>
>
>
> Am Mittwoch, 10. Juni 2015 02:02:15 UTC+2 schrieb Tim Graham:
>>
>> Carl proposed a similar thing: 
>> https://groups.google.com/d/msg/django-developers/qCjfOu-FPxQ/hccAcVChHMkJ
>> It would be a bit better than he outlined there with an LTS every 2 years 
>> instead of 3 as I proposed.
>>
>> It seems difficult to estimate how much such a policy would increase 
>> maintenance costs in Django itself. The current proposal already keeps 
>> features deprecated in 1.8 around an extra 8 months compared to the old 
>> scheme. Your suggestion extends this to 16 months (and for features 
>> deprecated in 1.9, an extra 8 months too). An interesting exercise would be 
>> to look through the features deprecated in 1.8 and try to guesstimate the 
>> maintenance costs of keeping them around longer. I guess such estimation 
>> will be basically impossible though -- only when working on new features 
>> will we realize if supporting old APIs will be annoying or a problem. The 
>> only thing that comes to my mind is dotted paths in reverse() and url() -- 
>> once we can remove that stuff the URL resolver is quick a bit simpler and I 
>> know Marten was planning for that to be gone with his GSoC URL proposal 
>> (although I guess the new API can probably be implemented without support 
>> for that anyway).
>>
>> For what it's worth, about 25% of survey respondents indicated when 
>> starting a new project they use LTS as opposed to the latest stable 
>> version. Are the benefits to that fraction of the community large enough to 
>> outweigh the costs?
>>
>> On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:
>>>
>>> Thanks Philippe for bringing this up. 
>>>
>>> I'm currently upgrading a large Django app with dozens of dependencies 
>>> from 1.4 to 1.8, here are some observations: 
>>> - Most popular and/or maintained libraries actually supports every 
>>> Django version between 1.4 to 1.8. (Many thanks to their maintainers!) 
>>> - Libraries that support 1.4 and 1.8 but not with a single version add a 
>>> lot more overhead to the upgrade process. 
>>> - Libraries have their own backwards incompatibilities and deprecations. 
>>> By itself it's easily manageable when the new version still support your 
>>> current Django version, but it gets messy when you need to upgrade both 
>>> Django and 3rd-party apps at the same time. 
>>>
>>> Obviously, no production projects should depend on an unsupported 
>>> version of Django, but you still need to upgrade to intermediary versions 
>>> as you work your way to the latest LTS. 3rd-party apps that support both 
>>> LTS have been a huge help to us: you can upgrade them making changes to 
>>> your project as required, then they stay out of the way when you upgrade 
>>> Django itself. I wouldn't consider that libraries still supporting Django 
>>> 1.5 are encouraging running unsupported versions of Django, they are just 
>>> providing an upgrade path. Without such upgrade paths in the Django 
>>> ecosystem, I think LTS while good on paper, are a bad idea in practice. 
>>>
>>> The new proposal to have an LTS every third release is an improvement 
>>> over the current situation since 3rd-party apps need to support one less 
>>> version to bridge between two LTS. But I'm not convinced with "deprecated 
>>> features won’t be dropped until the version those features were deprecated 
>>> in is no longer supported"; it adds overhead to Django's maintenance while 
>>> still requiring 3rd-party apps to create shims if they want to support both 
>>> LTS to ease with the upgrade process. 
>>>
>>> How about dropping all 

Re: Feature: URL template tag, optional parameters

[Tim Graham]

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.djangoproject.com/en/1.8/topics/http/urls/#specifying-defaults-for-view-arguments
> )
>
> For example,
>
> in url.py:
>
> url(r'^blog/page/(?P\d+)/$', views.page, name='view-page'),
> url(r'^blog/page/(?P\d+)/(?P[a-zA-Z0-9_.-])/$', views.
> page, name='view-page'),
>
> in views.py:
> # View (in blog/views.py)
> def page(request, page_pk, page_slug=""):
>
>
> However, in the templates, the url template tag can't accept optional 
> parameters.
> So instead of writing {% url 'view-page' page_pk page_slug %}, you need to 
> write {% if page_slug=="" %}{% url 'view-page' page_pk %}{% else %}{% url 
> 'view-page' page_pk page_slug %}{% endif %}
> On the project I'm working on I have 2 or more optional parameters, and 
> it's a real nuisance.
>
> The url tag could have done this logic by itself. If any of its inputs are 
> blank or none, disregard it.
>
> Same question from Stack Overflow (not asked by me) : 
> http://stackoverflow.com/questions/16870884/url-template-optional-param
>
> Thanks
>

-- 
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/9c67b646-ee16-4f82-a545-9e4178d4e7dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: App config on the default template for app creation

[Tim Graham]

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 and can also give 
> a proper name to their apps.
>

-- 
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/70e62e83-5f43-480d-88a1-3a0331d004f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: URL namespaces

[Tim Graham]

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 Sunday, June 7, 2015 at 3:29:56 PM UTC-4, Marten Kenbeek wrote:
>
> So 2) has been fixed (#24904 and #24906), and I got a PR for 1) (
> https://github.com/django/django/pull/4724). 
>
> About #24127: I see a few options here:
>
>
>1. A context processor or similar that sets `current_app` if it isn't 
>set. By default `current_app` doesn't exist, so there's a good distinction 
>between not set and set to `None`. This would be 100% backwards 
> compatible, 
>but IMO it's not the best solution in the long term. 
>2. Provide a new flag to {% url %} to reverse with current_app set to 
>request.resolver_match.namespace. This feels slightly less awkward than 
> the 
>current method recommended by the docs.
>3. Deprecating a non-existing current_app to force an explicit choice 
>between the old and new behaviour, then add the new behaviour after the 
>deprecation period. This would be coupled with option 1 for ease-of-use. 
>4. A setting? A setting! Yay, another setting...
>5. Document the slight backwards-incompatible change? And provide an 
>easy way to retain the old behaviour, of course. 1 through 4 are all far 
>from ideal, and I don't think there's an easy, backwards-compatible fix 
>here. 
>
> Thoughts?
>
> Op dinsdag 2 juni 2015 14:32:42 UTC+2 schreef Marten Kenbeek:
>>
>> The admin proves problematic. Looking at the uses of `AdminSite.name`, 
>> it's not easily replaced. There are quite a few places that use the name to 
>> reverse urls, but don't have access to the request and the current 
>> namespace. I think the best solution for now is to document that you should 
>> pass `admin.site.urls` directly to `url()`. `include()` does a bunch of 
>> stuff, but none of it is needed in the case of the admin urls. This allows 
>> the new `include()` API to be as intended, but it doesn't put an 
>> unnecessary burden of providing the "correct" namespace for an admin 
>> instance on the end-developer. 
>>
>> In time I'd like to see a method on the AdminSite that returns an actual 
>> resolver object, using the new API. The default URLconf template would 
>> simply look something like this:
>>
>> urlpatterns = [
>> admin.site.get_resolver('^admin/'),  # or 
>> get_resolver(RegexPattern('^admin/')) to be more explicit
>> ]
>>
>> This would solve the namespace issue for the admin, but it would still 
>> allow for only obvious way to set the instance namespace, and keep the 
>> `include()` API clean.
>>
>> Op zaterdag 30 mei 2015 14:28:22 UTC+2 schreef Tai Lee:
>>>
>>> Right. So if I understand correctly, you can avoid problems even when 
>>> installing two different apps into the same app namespace as long as you 
>>> *always* supply `current_app` when reversing URLs? In which case, I don't 
>>> think we need to worry about being able to change the app namespace to 
>>> avoid conflicts (maybe we should even disallow it), and instead just make 
>>> it easier to *always* supply `current_app`, which brings me to my next 
>>> point.
>>>
>>
>> Not providing an option in the API itself is the best we can do to 
>> disallow it. But yes, always setting the current_app would avoid a lot of 
>> problems. https://code.djangoproject.com/ticket/24127 proposes just 
>> that. 
>>
>> I'd take this a step further. In this comment -- 
>>> https://code.djangoproject.com/ticket/21927#comment:9 
>>> 
>>>  
>>> -- I made a suggestion that Django set a `current_app` hint in thread local 
>>> storage with a middleware class or even before middleware runs, and then 
>>> have `reverse()` and `{% url %}` fallback to that default hint ONLY if no 
>>> current app is explicitly provided via the current mechanisms, so it should 
>>> be a relatively safe change.
>>>
>>> This should make it much more convenient and possible to reverse URLs 
>>> correctly regardless of conflicting app namespaces, even in code that 
>>> doesn't have access to the request object. For example, model methods that 
>>> are executed in templates and do not have access to a `request` or 
>>> `RequestContext` object. As far as I know, 1 thread = 1 request, so using 
>>> thread local storage should be safe to provide such a hint for any code 
>>> that executes in response to a request. For management commands, it would 
>>> still need to be supplied explicitly. What do you think?
>>>
>>> Cheers.
>>> Tai.
>>>
>>
>> I don't think it's necessary to introduce another global state. At the 
>> moment there are a few places in the admin that use the name but don't have 
>> access to 

Re: Feature: Template Components

[Emil Stenström]

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  you need...
>
> Sounds interesting to me... I'd be happy to collaborate on it with you... 
> once we see where it goes, and compare it with the existing implementation, 
> people will have more food for thought :)
>

Sound like fun! I have a repository setup at 
https://github.com/EmilStenstrom/django-components and I've given you 
commit access. I've also started a chat channel connected to that repo so 
we can talk: https://gitter.im/EmilStenstrom/django-components

Looking forward to this! 

-- 
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/65f574d6-d5f1-497d-8bee-02202e798ae7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Michael Manfre]

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 if
> you started with 1.8 you are already on LTS. If you start with 1.9,
> you should have an easy upgrade path all the way till 2.1 which is
> LTS. Also upgrading from 1.8 to 2.1 should be easy enough if you
> didn't use any deprecated features when running on 1.8.
>
>  - Anssi
>
> On Thu, Jun 11, 2015 at 12:06 AM, Tim Graham  wrote:
> > Yep, I think Collin's schedule is it. I'm happy with that option and 3rd
> > party apps shouldn't need to add any compatibility shims to support 2
> > releases -- they just need to ensure they aren't using any deprecated
> APIs.
> >
> >
> > On Wednesday, June 10, 2015 at 3:48:39 PM UTC-4, Collin Anderson wrote:
> >>
> >> Hi Tim,
> >>
> >> What I mean is we could still make it easy to support both LTS releases,
> >> even if we drop features deprecated in 1.8 before the next LTS
> according to
> >> the normal release schedule. Right? Because apps wouldn't need to use
> those
> >> deprecated features to support both 1.8 and 2.1. We could drop them in
> 2.0
> >> like normal?
> >>
> >> I'm trying to lessen the increased maintenance burden of Loic's proposal
> >> while still making it possible to easily support both LTS releases.
> >>
> >> > For "maintenance costs" I am not worried about supported deprecated
> APIs
> >> > in old releases, only how long they stay around in master as that
> could be a
> >> > barrier to innovation.
> >> Right, so the cost would be an extra 8 months before removing features
> >> deprecated in 1.9 from master.
> >>
> >> Thanks,
> >> Collin
> >>
> >> On Wednesday, June 10, 2015 at 2:09:13 PM UTC-4, Tim Graham wrote:
> >>>
> >>> Collin, I'm not following your reasoning about why dropping features
> >>> deprecated in one LTS (e.g. 1.8) in the next LTS (e.g. 2.1; I think
> you made
> >>> a typo in your timeline putting it next to 2.0?) will make it possible
> to
> >>> easily support both LTS releases? That's the purpose of Loic's
> proposal I
> >>> believe.
> >>>
> >>> For "maintenance costs" I am not worried about supported deprecated
> APIs
> >>> in old releases, only how long they stay around in master as that
> could be a
> >>> barrier to innovation.
> >>>
> >>> On Wednesday, June 10, 2015 at 1:54:53 PM UTC-4, Collin Anderson wrote:
> 
>  On Friday, May 8, 2015 at 12:12:37 PM UTC-4, Carl Meyer wrote:
> >
> > And there is a significant added maintenance cost to my proposal
> > compared to yours. Dropping deprecated APIs in the release after an
> LTS
> > means we still have to support those APIs for three more years
> > (possibly
> > for four or five years after they were first deprecated). Dropping
> them
> > _in_ the LTS release shortens that window drastically.
> 
> 
>  If we release every 8 months, that means we normally support
> deprecated
>  features for 2 years. If we maintained LTS compatibility, then, yes,
> that
>  would mean "supporting" the APIs for more than 5 years after
> deprecation.
>  But to be clear, most of that time it's only security support for
> those
>  APIs, and the APIs are long gone from master. Right?
> 
>  Thanks,
>  Collin
> 
> 
>  On Wednesday, June 10, 2015 at 1:37:30 PM UTC-4, Collin Anderson
> wrote:
> >
> > Hi All,
> >
> > Here are some thoughts in reply to some of the comments in the
> > django-compat thread. I don't stick to the LTSs myself, but I've
> helped
> > maintain apps that have 1.4 compatibility.
> >
> > On Tuesday, June 9, 2015 at 7:05:45 PM UTC-4, Loïc Bistuer wrote:
> >>
> >> 1.8 (LTS): No features dropped.
> >> 1.9: Dropped features deprecated in 1.4, 1.5, 1.6, 1.7
> >> 2.0: No features dropped.
> >> 2.1 (LTS): No features dropped.
> >> 2.2: Dropped features deprecated in 1.8, 1.9, 2.0
> >
> >
> > 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).
> >
>