Friday, September 29, 2006

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 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 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 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, 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?


Blogger Michael Scharf said...

Hi John,

I'm a bit split with the releases I use: on one hand I want to be up to date on the other hand, it's always a risk to update something in a running system. I think the eclipse update manager is (well let me say it politically correct) it is suboptimal.

If I would use the nightly build or the integration build of all plugins, I would spend quite some time updating. That's why I bought the distribution. Unfortunately they are not really fast in catching up the "latest and greatest" versions of plugins.

For me, the update problem is still unsolved...


6:24 PM

Blogger Michael Scharf said...

Hi John,

I'm a bit split on what to do. Getting the 'latest and greatest' of all plugins I use would take very much time. Especially, because the update manager is, well, (I don't want to use bad words) suboptimal.

Its also difficult to communicate with other people in the team, when everybody uses different versions of plugins: "I can't find this menu entry" -- "which version do you have installed?"...

I use the distribution for most of the plugins. Yoxos comes up with new versions a few times a year. And often they don't include the 'latest and greatest'. Only a few plugins I keep more up to date.

Keeping up-to-date and managing different versions in an eclipse installation remains a major challenge...


6:29 PM


Post a Comment

<< Home