Am Donnerstag, 26. Juni 2008 18:30:12 schrieb J Meier: > Hi folks, > > I'm trying to champion Django trunk/1.0 as part of a small project in > a mid-sized city newspaper office. There is some worry about choosing > a framework which does not currently have a stable release. I've been > addressing these worries with examples of the stability of trunk and > the excellent planning and engineering of the project in general. > Never the less, it would be valuable to me to have testimonials from > others using or targeting trunk/1.0 in their applications, especially > from traditional businesses. I think such testimonials could also help > others get steam behind the 1.0 effort in organizations which are wary > of support and stability. > > So I'd like to request that, if you have time and inclination, such > users would post or email testimonials explaining your use of Django, > experience with it's stability over time, confidence in the core > developers, and (and here's where the higher-ups are interested) the > size and nature of your project and company.
We are currently running trunk on two production sites, the larger one getting about 10k hits/day (ef-magazin.de, a small newspaper in German). Never ran into real problems because of being on trunk, however we do have a proper development/test/production landscape in place, and ensure every update gets sufficient testing before going into production. As others have pointed out, API changes are documented quite well, so it is really not difficult to upgrade and find out what went wrong (if any, it rarely happens). However it must be noted that since the merge of queryset-refactor, some things in admin do not work as expected: - multi-table model inheritance in admin is broken (Ticket #7349) - inline editing of user profiles is broken (Ticket #7370) It is very likely these bugs won't get fixed in oldforms-admin. But OTOH, if you are planning to use admin extensively you'll probably want to go with newforms-admin branch anyway. IMO, to maintain a stable and reliable system, it is not really important that the software used has a certain version number, but that there is a test plan and a proper test infrastructure in place, and that these tests are actually conducted each time before releasing changes into the wild. Whether to use unit testing or doctests or simple manual testing is a matter of taste, I personally found that often it is much faster just having a Word document outlining the necessary test steps, and have a good tester (which doesn't need to be a technical person; in fact I prefer asking end users whether they want to help with that, which also helps understanding their needs and usage patterns better) execute them. The test system should be as similar as possible to the production system, at least it should have the same OS and DB as a production server, and should be refreshed regularly from the production DB. Make sure you have a defined and automated rollout procedure in place, as that lowers the chance that the develop->test->release cycle gets circumvented because "we have no time for that" and/or "it's just a small fix, so I can do it on the production machine directly". And, as a last tip: try to use the same db type throughout development, test and production, read: avoid sqlite like hell, except if you are using it in production too. The comfort of a local sqlite db comes for the price of getting all these nasty unique key constraint etc. problems in test, which you simply do not see in development (as sqlite doesn't support them). regards, chris --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
