I am in the process of deciding what to use for a site I hope will be very significant in its scope and reach. And speaking geographically, I would like to use it as the kernel of a Django community in Western Canada (where there are thousands of Python programmers, many using Plone and Zope for things Django might do better).
Because I am in the position of betting my job on Django, and others may well be in the same situation, I'll ask more direct questions than I usually would: * is there a Django 1.0 schedule? * does Django 1.0 have a scope statement? * are these available on the Web or could they be made so? I think I may represent many people when I say that I am potentially in the position of betting my job on Django in general and the timely release of Django 1.0. If our site goes live and a bug is found, and we blame it on Django, our boss will not say "well, all software has bugs." He'll say: "Why did you use a pre-1.0 product rather than Rails, which is shipping, available and proven." To be perfectly blunt, the version number matters to me in my job situation. If version numbers were meaningless then we could just bless Django at 1.0 at any time. But they have meaning. They mean API stability, a higher level of QA and a much improved marketing story. When I first told my boss about Django, he said that the fact that it wasn't 1.0 was a show-stopper. I understand his position. He's pretty much betting his job too. I've been program manager for several products. It would make me very nervous to have 7 brranches open six months after the first scheduled release date flew by and a few months after the second one. As a potentially betting-the-job consumer, I have to admit I'm nervous now. I cannot imagine how those branches could possibly safely be merged at a rate faster than one per month (given everyone has day jobs, and the testing requirements are high). So Django 1.0 would be more than a year after the February/March that was originally described. Even if I were the program manager, it would be rude to tell developers: "You should work harder." It would be even more rude to say that in an open source project. Instead, I would suggest that you've got to make some hard choices about which of these features will have to wait until 1.1 or 2.0. My outsider's impression is that over the last year, Django has been feature creeping like crazy and that at the current rate there will never be a 1.0. Turbogears will get to 1.0. Rails may get to some other new version number and Django will still be marketed as API-unstable beta software. In particular, if I were project lead for Django, I would probably delay all of the branches. The backwards compatible ones would go in Django 1.1. The incompatible ones would go in Django 2.0. When I am program managing a product, I would ask which is more likely to harm the product's success, a further delay or a missing feature. I cannot possibly imagine the lack of features on the branches will harm Django more than further schedule slips. The community knows that they are coming. I'm not usually in the business of telling open source developers when they should release their product so let me just state it this way: if Django developers cannot lay out a believable public plan of how they will get from here to 1.0, then I cannot use it which will be a great personal loss. In addition, Django is not just Django. Python itself is depending on Django and/or Turbogears for its continued growth as a cutting edge language for modern Web applications. Paul Prescod --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---
