Thanks for opening this discussion. Am I only one who see the django improvement process too slow? I mean refactoring, decoupling and making code more reusable in the time when we realize that previous design has too much constraints and there should be better design now.
I know there's django deprecation policy nicely documented http://docs.djangoproject.com/en/1.1/internals/release-process/#internal-release-deprecation-policy But what I don't know is how you discover it. Is it described somewhere in the text or the video from conference? What were the reasons to have this deprecation policy? Was there any user research? Research of when the django users upgrade, what are the main problems of upgrades and how they imagine upgrading should work? I saw in the discussion in this thread http://groups.google.cz/group/django-developers/browse_thread/thread/a89935f2f9f9102b that Russell wrote: "Put it this way - If part of your migration plan involves every one user of Django carefully reading the and following the upgrade instructions, then I want your home phone number so I can give it to everyone that contacts me personally complaining about their broken Django installs. And be warned -- I'm in a timezone that guarantees you will be called at three in the morning. :-)" I think this problem could be solved by other ways than setting the strong deprecation policy. (Eg. more visible of release changes, not providing support for free or get out the "unaware" users out of the community just by the "faster" upgrade policy). What I try to say is that I'm little bit afraid that it seems like improvements of django will take years instead of months. In the time when Rails 3 is coming it looks like the next killer framework in terms of easy-to-use and also power and extendability. The django core devs are doing great job but it's sure there's and still will be a lot of new use cases for django in the various web applications discovered by community. I think this could lead to fork the django by some devs and rapid development of this fork. Maybe then in one moment there would rise the discussion about merging these two and it will take year (as in Merb & Rails case). Is this the best way of development OS? Vaclav On 5 dub, 05:02, orokusaki <flashdesign...@gmail.com> wrote: > This is a bit abstract, but I'd like to bring up this idea, and > firstly let me say that I don't intend to waste the time of the major > contributors (unless you want to join in of course). I mostly want to > get an idea of what some of the contributors/feature proposers out > there are thinking of, in a sort of fly by the seat of your pants way. > > Through reading some of the ideas/problems on this group (including my > own) I've noticed that some tend to be A) too far in the future, B) > too abstract, C) (very important) Backwards incompatible, D) (very > important) Too much architecture changes. The discussions tend to turn > from macro to micro very quickly because of some of the existing > constraints. > > 2 thoughts came to mind: > > 1) What if every major element could be re-factored for better > extensibility (and perhaps speed as well) without regard for the > backwards compatibility. > 2) Imagine the progress that could be made if the existing code base > was able to be re-factored in one week (impossible of course, but > hypothetically speaking), knowing everything that the developers know > now. > > I know neither of those is possible at the moment, but take those two > ideas (rules) in mind, and talk about what you'd add / change / make > better / etc. > > Perhaps this is way more 2.0 than even 1.3, but I wanted to get a very > early look through foggy goggles into the future so that I can come up > with ideas. I've been bombarding Russell K M with questions, thoughts, > etc that are just very poorly timed with 1.2 Beta and all, and I want > to step back and really prepare for next time. > > 2 related questions for anyone who cares to answer: > > 1) Is anything allowed to become non-backwards compatible during a .x > release? (ie, from 1.2 to 1.3 or 1.4) > 2) When will 2.0 development begin? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
