Callisto maintenance release complete, but…

DTP released 0.9.1 with the rest of the Callisto maintenance stream this week. This has got me to thinking about what a “release” means at Eclipse.

I’m often asked about which build of DTP should be used, and usually there's some surprise when I say to use the latest nightly one: seems that a lot of people are in the habit of using only releases or at least milestones. I started wondering why this preference exists. In a closed development effort, there’s essentially a black box into which you insert requirements, and out pops some software. There isn’t a choice here – you wait until it is “done” and take what you get at that point (“beta” not withstanding). Another factor might be waterfall-ish development processes: there’s a long period in which new features are added, but stability is not a concern. Next, there is a (often much longer) period trying to stabilize the code line.

But a strong majority of projects at eclipse.org use agility-inspired methods, especially tight iteration cycles of plan-do-finalize. Also, the current state of the project is transparent through Bugzilla, the mailing lists, newsgroups, published documents, and so on. A consumer can see (granted, with some effort) the current and projected state of the project at any time. This visibility would seem to enable frequent integration.

So, what do you get from a “release” at eclipse.org? There is some ceremony around the release event, including a release and intellectual property (IP) reviews. Given the transparent nature of project day-to-day operations, I’d be surprised if anything was a revelation during a release review. Also, each eclipse.org committer has studied the IP policies and respective PMCs police these areas. Perhaps the notion of “release” is related to closure, a time to stop and pat ourselves on our virtual backs for a job well done.

Anyway, for DTP and projects I work with at eclipse.org, there is a strong incentive to stay as close to the current code line as possible. I can say that DTP gets better over time – more features, more bugs fixed – and so using the latest is desirable. Sure, we make mistakes and introduce new bugs, but it is a lot easier to find and fix these when more eyeballs are closer to the build cycle. Also, if you do find bugs, missing features, or other things that you don’t like, then telling a project about such issues close to a release date usually means that you get a response like “good point – maybe in the next release.” Now, I assume that you don’t like that kind of answer, and I can tell you that we don’t like having to say it. During the ebb and flow of a development cycle, though, we might not be able to address an issue immediately, but at least we have a lot more flexibility to weave it into the project plan.

But that’s just me, how about you? Do you use releases/milestones or current builds? If releases/milestones, but would prefer using current builds, then what makes it hard to do so?