Hi,
We've been able to do quite painless upgrades to our software as well.
Considering that we started with Django 1.1, stuck quite while at 1.3 and
recently we did upgrade to 1.5
Most notable change was {% url %} tag, but nothing really major.
Though we don't use many external libs - we've b
Florian
Here are wc -l line counts:
Project 1
.py 28574
.html 16967
(this is a little misleading because we don't use model.py but a separate REST
API to handle all the storage)
Project 2
.py 43199
.html 91804
Project 3
.py 32441
.html 86684
Cheers
François
On Aug 13, 2013, at 12:31 PM,
Hi François,
On Tuesday, August 13, 2013 5:46:10 PM UTC+2, François Schiettecatte wrote:
>
> I have done 1.3.x -> 1.4.x -> 1.5.x and they have all been painless, each
> migration taking less than 1/2 day. Point being that back-porting is not
> something I would ever need.
>
It's good to hear t
Hi
Not sure if this is useful, but I thought it might be helpful to throw my
perspective as someone who has built four sites with Django (two of which are
public, and one of those has to be HIPAA compliant). I will update to dot
releases after the main release to give the main release time to s
On Aug 13, 2013, at 11:34 AM, Michael Manfre wrote:
> If there is interest in the community to backport security fixes to no longer
> supported versions of Django, what is the likelihood that a core dev would
> merge them in to the appropriate stable branch? This would not include
> packaging
If there is interest in the community to backport security fixes to no
longer supported versions of Django, what is the likelihood that a core dev
would merge them in to the appropriate stable branch? This would not
include packaging an official release, but would provide a way for those
stuck on o
I'm sorry; I was snarkier and nastier than I should have been (and than I
intended to be). Thanks for calling me on it; I'll try to do better next
time.
Jacob
On Tue, Aug 13, 2013 at 10:03 AM, Andre Terra wrote:
> On Tue, Aug 13, 2013 at 9:22 AM, Jacob Kaplan-Moss wrote:
>
>>
>>
>>> We have ap
On Tue, Aug 13, 2013 at 9:22 AM, Jacob Kaplan-Moss wrote:
>
>
>> We have apps in production running Django 1.3. There won't be any
>> security fixes. If there's a critical vulnerability, we may have to do a
>> lot of unpaid work to either backport the fix,
>
>
> I have to say I find this kinda hil
On Tue, Aug 13, 2013 at 1:37 AM, Chris Wilson wrote:
> I would love to see support extended for a bit longer after deprecation.
This is a matter of resources; we struggle to maintain security releases
against 3 simultaneous releases (e.g. right now 1.4.x, 1.5.x, and the
up-coming 1.6). Adding a
2013/8/13 Chris Wilson
> It certainly seems that people are eager to rip things out the very second
> that the deprecation waiting period expires and they are "allowed" to.
If someone introduced a deprecation with a PendingDeprecationWarning, and
someone else later advanced all PendingDeprecati
Hi all,
On Mon, 12 Aug 2013, Jacob Kaplan-Moss wrote:
If you'd like to help push us closer to where *you* think the right
place balance is, the best thing to do is to watch our development
process and speak up in the moment. These sorts of general, post-facto
observations don't give us a ton
Hi Simon -
Here's the thing: I'm sensitive to the fact that you think we're moving too
fast, but you have to understand that we also hear that we're moving too
*slow*. We have to strike a balance, and I'm happy where we've struck that
balance.
If you'd like to help push us closer to where *you* t
On Monday, 12 August 2013 17:23:40 UTC+10, Aymeric Augustin wrote:
>
> It would be interesting to describe what actual problems these libraries
> encountered. Were they caused by actual deprecations or by changes in
> private APIs?
>
One example would be simplejson, why not leave a stub there
On 12 août 2013, at 06:21, Simon Litchfield wrote:
> Celery, sorl-thumbnail, mptt, registration, shorturls, compressor, tinymce (I
> could go on) have been having trouble keeping up.
Hi Simon,
It would be interesting to describe what actual problems these libraries
encountered. Were they cau
Hi,
On Monday, August 12, 2013 6:21:46 AM UTC+2, Simon Litchfield wrote:
>
> One of Django's key strengths is the large collection of apps. Some aren't
> as regularly maintained as we'd like but we still love them. Is it a little
> unreasonable to expect them all to move so fast?
>
Fast? Imo th
Hi Simon,
On Mon, Aug 12, 2013 at 12:21 PM, Simon Litchfield wrote:
> It's great all the housekeeping we've been doing lately, and I'm sure we
> all agree nice to have clean, tidy code; but I wonder if we've been a
> little too unforgiving at the expense of easy compatibility with important
> thi
It's great all the housekeeping we've been doing lately, and I'm sure we
all agree nice to have clean, tidy code; but I wonder if we've been a
little too unforgiving at the expense of easy compatibility with important
third party apps?
Celery, sorl-thumbnail, mptt, registration, shorturls, comp
17 matches
Mail list logo