On a recent plane ride, I was watching an episode of The West Wing which had flashbacks to the original campaign which set up the Presidency on which the show is based. There’s a scene in that episode where Abbey Bartlet — the eventual First Lady on the show — is talking to some of her husband’s campaign staffers about whether her husband is ready to really run the campaign and be President. The dialogue is classic:
JOSH: Well, is he going to be ready?
ABBEY: You bet your ass he will. In the meantime, you want to kick something? Kick me.
If you don’t think Django releases come often enough, or that there’s something desperately wrong with the release system, or that Django isn’t ready for 1.0 or won’t be or, basically, have any concerns of the sort: please don’t post uninformed blog entries attacking the dev team. Please don’t try to “helpfully nudge” them out of concern for the project. They know what they’re doing, they know what needs to be done and they’re getting it done.
Come yell at me instead and get it out of your system. I’m the release manager, which mostly means I do behind-the-scenes bureaucracy, but I’ll be happy to listen to you and take the time to talk things through if that’s what you want. I’ll also be happy to just sit and let you yell at me, if that’s all you want to do.
The list of necessary things to happen before 1.0 is out in public, because Django has a transparent development process; you can see what’s happening as it happens. The reason why there hasn’t been an interim pre-1.0 release is also out in public, for the same reasons. If you’re concerned or curious about Django development, the information’s all out there, so you can do as much or as little due diligence as you’d like. And if you’ve got the time and the energy, consider pitching in and helping with bugfixes or with the work on major changes like newforms-admin.
Django 1.0 will happen and it will rock. In the meantime, you want to kick something? Kick me.
Comments for this entry are closed. If you'd like to share your thoughts on this entry with me, please contact me directly.
-1
+1
Consider yourself kicked. Django needs to merge the last few bits, let them shake out, and ship 1.0. And it needs it badly, for a whole host of very good reasons.
Hi Happy Django User: please feel free to join us on django-dev and let us know which bits you’d like to see merged and how you’d like to help out!
Is this the current path to 1.0?
And thanks for your work on Django.
Absolutely no concerns about this - I trust you guys and keeping it in public helps immensely.
Well, I just started using Django after looking at some of the available frameworks and I see no problem in using “trunk” - I ran in a little problem I didn’t know why this was happening (autoescaping on by default) but thanks to the really helpful and friendly #django channel on freenode it was a matter of seconds to fix it.
If someone doesn’t want to run in such problems were is the problem using 0.96 AFAIK it is stable and work.
All I can say is thanks for the great framework.
-1
Anyone who watched the pathetic way that the whole Favicon issue was “handled” by the Powers That Be knows how well sitting down and shutting up works in Djangoland.
Also: it’s painfully obvious who this post was aimed at (both of your blogs are in the feed on the main Django Community page for pete’s sake!) so if you’re going to post this sort of lame response to what someone else has written you might want to at least man up enough to post it ON THE BLOG IN QUESTION; posting it like this is just sad. (and if you read Jacob’s comment on that blog BEFORE you posted this …. ‘ironic’ doesn’t even begin to cover it … )
And cue the folks who just want to yell. Let me know when you’ve got it out of your system, OK?
@Joe: I’ve done a little work on updating and expanding that page, so yes, it’s pretty accurate right now. I’ve also added a link on that page to the post on the developers mailing list where the list of 1.0 features and rationale for each was outlined.
I’m not happy with Django not having a release since over a year, but this is more of a problem to the company I’m working for than for me personally. Anyway, Django is good piece of software even in ancient 0.96 version so we will continue using it until next “official” version arrives (and then we’ll see if the update is feasible at all). We learned to live with this version’s shortcomings and we are here for making money, not for looking for developer’s happiness. This is how life goes.
I just cann’t pass the fanboys that say you have uncoditionally go django-trunk.
And, of course, the company can always ask for a refund if they find they’re unhappy with Django.
I understand why 1.0 isn’t out yet, but why are we at 0.96 and not in 0.97? If you claim the trunk is “stable enough”, why not bump the version?
If there is an official reason for this listed somewhere on the website, please link to it here, or better yet, link it in the FAQ.
The reason why there hasn’t been an interim pre-1.0 release is also out in public, for the same reasons - this is not as easy to find as the version 1.0 required features.
+1 James
And here’s a more articulate response and a bit of background. Call me a lone-cowboy-coder or a Django fanboy because that’s probably a pretty good picture of myself when I’m not coding for my employer.
I’ve been always coding against trunk because that’s what the dev-team hinted we users should do before a 1.0 would be out.
That said, time is what I value the most, because I code 8 hours for my employer and come back home hacking on my Django projects. Developing against trunk takes me an occasional (every month or so) 30 minutes to 1 hour upgrade/fix/regress/deploy cycle. Granted, my app are small-ish, and I don’t have formal QA to pass but if I need a new feature that’s just been merged I’ll just have to do the upgrade, if I don’t I’ll just code against a random rev until I’m forced to upgrade.
If you have a formal release process, have your custom deployment/upgrade scripts handy, it can be really smooth to upgrade, so no, I can’t see your use-case for NOT working against trunk zgoda, even if you’re working for a big company. And if the management doesn’t allow you otherwise well… either you’re not making a good enough argument to them or you should be using something safer (LOL!) like raw .NET or PHP with all that it entails.
The reason why there hasn’t been a 0.97 or other interim release is generally mentioned on the mailing list whenever someone asks about it: simply put, pushing releases introduces work both for the Django team and for people who use Django.
For the Django dev team, it means doing QA, going through the bureaucracy of tagging and announcing the release, coordinating with downstream distributors and then maintaining support for the release over its lifetime.
For people who use Django, it means going through the release notes, noting any changes, and then doing rounds of QA and development to bring their own code up to the new release.
One thing that’s often overlooked is that — right now, as we work through the last set of big changes before 1.0 and the backwards-compatibility guarantee that needs to come with it — this means that more frequent releases would impose more and significant overhead on people who use Django, because they’d need to go through multiple cycles of upgrades and testing. And since any interim release would have to come with a caveat of “upgrade, but bear in mind there’ll be more changes before 1.0”, it doesn’t really strike me as a smart thing to do.
When 0.96 went out, the accompanying release notes explicitly mentioned that it was meant to be a stable platform for people to use while the remaining pre-1.0 changes were worked out, which is pretty much the same deal: rather than force people to go through multiple upgrade cycles as each change or set of changes landed, it seemed (and to me, still seems) better to just hold off and ask people to upgrade once — to 1.0 — and maintain compatibility going forward from that.
@Edgars, @James: I’m a django user, as such, I read the occasional blog post and the main documentation of the project. I don’t read django-dev and I’m not familiar with every wiki page. I’m sure that there are django users or would-be users which don’t even read “django community” posts.
Telling me that there is good reason for something and saying “its out there, everyone read it already” or worse, “its out there, go find it yourself” just isn’t enough if you want to convince me that the current way is the right way(TM) to do django releases.
please link so I can read your arguments, or write them here.
@James: sorry, posted before I saw your reply.
@Lorenzo: I’m in a similar situation as you: except I code against trunk at work and at home. I’ve only been using Django for 5 months (On multiple sites) and have never experienced a problem with running “svn update.”
Yes, and no-one’s suggested that every single person who uses Django should do this.
However, someone who wants to follow along with development or get a feel for where things are in the run up to 1.0 probably should be looking at the available information. And that’s true of pretty much any project with an open development process: you don’t have to read dev lists or bug trackers just to use the software, but if you want to know what’s going on in the dev process you should start by looking at the publicly-available information.
Just wanted to add my 2cents, and let everyone know that I’m perfectly happy with the current trunk. It’s stable, well featured, and has all sorts of awesomeness that just can’t be found in competing products.
Not to mention: Coolest name ever.
Thanks for your hard work James! I’m looking forward to purchasing your book!
I love Django, and use the current trunk with my work. But lets be clear, that’s not the best way to be doing things. What we need is a release that’s stable and recent enough that we can standardize across a series of machines. Why not provide intermediate releases every 3 months? Or even 6 months? Consider that my kick.
Perhaps a stance like this would be a little more friendly.
“We know that in comparison to other open source projects our stance on releasing is a little different, so we’re asking you to stand open for our different way of doing stuff and this is why: ’…’”
It could be a little less provoking. On the other hand, keep going guys! Django is brilliant and it helped me a lot in my projects. I think that the vast majority is just shutting up about this knowing everything will come out just fine (where with fine I mean absolutely fantastic)
Lars, as far as I know nobody on the dev team has disagreed with the idea of doing more frequent, scheduled releases after 1.0 lands; in fact, it’s quite a popular idea and may well be what ends up happening. But for the reasons I’ve explained above, interim releases between now and 1.0 probably aren’t a good idea.
What’s the problem here? Simply use svn externals and fix the revision number. Update to the latest version of trunk when you feel like it. Trunk feels pretty damn stable to me. Maybe there should simply be no releases, but a constantly stable trunk :)
I don’t think anyone in the dev team was counting on the amount of buzz that Django would get over the last year or so. It must be a bit frustrating for it to happen while trying to manage big changes like newforms-admin.
I can sympathize with both points of view, but svn update is so easy and trunk so stable, I’m definitely +1 on letting Jakob, James, et al exercise their own judgement on when to do an official release.
Good to see you in the comments on your own site again. This place was starting to look like a polished mirror.
-1
In case anyone is wondering, I think this post is in reference to technobabble’s post.
He wasn’t impolite or attacking the dev team. His post was pretty nice actually (especially when he mentions how Django is the best thing that happened to web development).
I’m pretty surprised that people are getting so defensive about this, especially since Django developers usually try to stay out of flame wars about tools.
Don’t, don’t ever bring 1 out . I warn you then every body will starting using Django and I will lose the “cool” factor. aarrrggggghhhh
James,
-1
sounds a bit like Django has a release manager who doesn’t like to work with releasing things…. (my kick)
or are you working so much preparing the 1.0 release right now, that you dont’t have time to work on a pre-1.0 release? when’s 1.0 coming out then?
and how is this more cumbersome than keeping up-to-date with trunk on several production sites? oh wait, if we think thats cumbersome, we shouldn’t do that then, right? we should use the last release from 1.5years ago and forego all the nice new features that came in since then while waiting for 1.0?
If thats your stance, you could at least give 1.0 a release date!
Or else, you should concede that people are using trunk in production, not happy to stick to just 0.96, and that interim releases would make those peoples lives easier (the majority of django users out there I presume)
Just say something like this instead?
“We understand, the point made about missing interim releases is valid. But we are lacking resources and busy working with 1.0 right now. We intend to ship 1.0 in autumn 2008”
It doesn’t really matter to me when an “official” release happens, but the points you have made about a pre 1.0 release is on shaky ground. Why release 1.0? People are just going to have to upgrade at 2.0 .. but why stop there.. what about 3.0? Why not wait until 5.0 before a release.. that will solve the problem of people being “bothered” of upgrading 4 times!
releases happen and people upgrade. It will happen at
That being said, the situation is as the situation is. If you want to use updated code, go with trunk, or make your own “un-official” releases.
Your argument doesn’t hold water. The problem is that adopting a forced-frequent release schedule prior to 1.0 would put people through multiple major backwards-incompatible upgrades within a relatively short period of time. Folks who’ve been tracking trunk through the Unicode merge, the autoescape change and queryset-refactor can attest to the fact that, in the current pre-1.0 runup, major backwards-incompatible changes are happening more frequently than, say, every six months (which is what a lot of people have asked for as the current release cycle).
And doing that would just get people riled up and demanding that the cycle slow down so that people don’t have to be constantly upgrading — there’d be the same complaints about upgrades and features and application compatibility, but they’d be talking about release numbers instead of major moments in trunk.
Meanwhile, after 1.0 when we know that APIs and such will be stable and backwards compatibility will exist from one release to the next, it’ll be much easier to do more frequent 1.x releases.
In other words, what I’m saying is that if we did much more frequent releases it’d likely devolve into a case of “I just upgraded Django to deal with this big change and went through all that hassle, but I’ll have to do it again in two months when the next big change lands”. And that’s not a cool thing to do to people.
I wonder why people are so crazy about this “1.0 release”, as far as I’m concern Django is quite a very good framework already.
Your argument doesn’t hold water, either. You aren’t forcing people to upgrade by releasing an update.
Michael, if they’re not going to upgrade then why are they so all-fired upset about not having a release to upgrade to?
Thanks for the update, James. We’re using trunk and are happy, and appreciate the transparency on getting to 1.0.
Some will upgrade. Those who want some of the newer features while being able to standardize on a release. And they’ll be that much closer to ready once 1.0 comes around. Future updates won’t impact them as much.
Others might not upgrade. Those who might not be comfortable with migrations or just want to do one large migration whenever 1.0 comes around.
But people will at least have the option. The same option they have for new releases of any software, OS, whatever.
This is what most of the users are doing already when they do their occasional “svn up” and find that something broke.
Actually, in my experience the backwards-incompatible changes aren’t even that big of a deal to handle so this whole argument seems silly.
And let’s not forget people starting new Django projects. It’d be nice if the big glaring green button on the Django homepage actually pointed to something halfway recent and was something that people could use on their new projects.
P.S. I really do love Django. And I use trunk. I just don’t buy the arguments for not having any intermediate releases.
James,
I admire your patience.
I’m shipping Django on a platform that uses the web for server management, so it’ll go and upgrade thousands of servers in the field. It makes my fellows a lot more comfortable when I say we’re packaging 0.96 than telling them that it’s a trunk snapshot from last week.
Using 0.96 and waiting for 1.0 is fine, right up until someone tells me, “please don’t use 0.96 if possible”. And they do tell me that.
So, what do I do now?
What happened to “release early, release often”? It’s a model that works. Really.
For the projects I’m working on personally, tracking trunk is no problem at all. The product is relatively stable and backward incompatibilities are easily dealt with.
The only concern I have with the time it’s taking for 1.0 to arrive, is that it has to reach this mark to be seriously considered for significant projects in most larger organizations. The tremendous momentum that Django is currently enjoying argues against this, but I’d hate to see that momentum sag if 1.0 is too long in coming. The ultimate success of a platform like Django comes when it pushes past the excitement of early adopters to the stable and sustained growth provided by institutional buy-in.
That said, my kick isn’t at the Django development team or its release manager, but rather at the lazy (or “too busy elsewhere”) bums like me that haven’t gotten involved in pushing the ball over the goal.
Keep up the great work James. Our appreciation (and good intentions) are with you!