Hi Pkl,
Sorry for slow reply, but I thought this was worth it:
On 03/09/14 20:45, Pkl wrote:
> Concerning the "rules of open source", I've yet to find a satisfying way
> to apply them regarding these "micro breaks". Imagine that project
> "myvideoplugin" is unmaintained (not handling PR) :
On 03/09/14 14:21, Anssi Kääriäinen wrote:
> For example, lets consider the get_query_set() -> get_queryset() naming
> change done in 1.6. If 3rd party library writers change the method name
> to get_queryset() for 1.6, then their code won't work in 1.5. If they
> don't do the change, then all
Considering we're trying to come out with more frequent releases, I wonder
if it would sometimes make sense to sometimes have a 3-release deprecation
for some features.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from
Hello,
Hello,
My apologies for sounding rude, and for raising these issues so late.
Yes, upgrading a project itself is a matter of a pair of evenings, the
problem is with third-party libraries, and more again, plugins of
third-party libraries (especially CMS-related).
I've had to bundle a
On Wed, 2014-09-03 at 14:46 +0200, Aymeric Augustin wrote:
> 1.5 and 1.6 must have been easier than 1.4. 1.7 may be more difficult
> because
> of migrations and app-loading. If anyone has improvements to suggest
> for the
> documentation, please do!
We could perhaps have better documentation of
2014-09-03 10:40 GMT+02:00 Tom Evans :
>
> I think it was more distraction by topics he had not come across. We
> set him off by saying "look at the release notes, go thru each change
> in turn, see if we are affected and what we need to fix it".
>
Thanks Tom for the
On Tue, Sep 2, 2014 at 2:53 PM, Aymeric Augustin
wrote:
> 2014-09-02 15:33 GMT+02:00 Tom Evans :
>
>> this story was scored
>> at 8 points, it took a junior developer much longer than 8 points and
>> wasn't finished in a single sprint
Pkl,
You shouldn't have to upgrade all your old sites to the latest version of
Django, unless you want maintain current methods.
This is why we like virtual environments, much.
The core team has made a nice set of security releases available via pip.
Django 1.4.14, Django 1.5.9, Django
2014-09-02 15:33 GMT+02:00 Tom Evans :
> this story was scored
> at 8 points, it took a junior developer much longer than 8 points and
> wasn't finished in a single sprint - and 1.3->1.4 was *easy*
>
I don't know how much a point or a sprint is worth in this context :-/
On Mon, Sep 1, 2014 at 9:45 PM, Pkl wrote:
>
> Hello,
>
> I once was once lured to an ideal of long-term stability and
> retrocompatibility, by nice docs like this one :
> https://docs.djangoproject.com/en/dev/misc/api-stability/
>
> But for some years, stuffs have
With as many new frameworks as there are out there, with the gains in
popularity seen in Go and Node, my thinking is, move quickly, break (some very
small) things, or die slowly. As was said, if your favorite lib doesn't work
with 1.6 or 1.7, either use a prior version, or spend some time
Hello,
While I generally agree with what other core devs have said regarding the
examples you raised, I still find your feedback interesting because it
reminds us that we iterate too quickly for at least some parts of the
community.
It's unavoidable that some people will find the pace of
Hi Pkl,
On Monday, September 1, 2014 10:45:30 PM UTC+2, Pkl wrote:
>
> In random order, I stumbled upon:
> - removal of django.conf.urls.defaults
> - removal of markup contrib lib (adios built-in RST support)
> - removal of request.raw_post_data (thus breaking about all existing
> webservice
Apologies if this does not directly address your points, but I recently
took over a Django site still running 1.1. I brought it fully up to 1.6 in
under 2 hours work, including rearranging the project structure, updating
settings, URL tags, import paths, switching to pip from buildout etc.
Mostly for clarity and historical purpose, I'd like to expand on the points
you listed.
Do not take this in any way as a dismissal of the issues you've raised.
On 2 September 2014 06:45, Pkl wrote:
>
> Hello,
>
> I once was once lured to an ideal of long-term
Pkl, if you're interested, I'd encourage you to be more involved in the
development process including this mailing list when changes are proposed.
I'm afraid raising a whole bunch of old issues that have already been
discussed and decided isn't that helpful.
Our deprecation policy (as you
I agree that there have been a lot of backwards-incompatible changes over
the last few years clean up the API. We've really been in "get stuff done"
mode.
I do however think it's a not good idea to break all compatibility in one
single shot. Python 3 did this and 6 years later it's still
17 matches
Mail list logo