the Fiddler's picture

OpenTK release strategy

Right now, there is no set schedule for new OpenTK releases. There is a rough list of features for each version, which is released when these features are more or less implemented. The main disadvantage here is that it's difficult to estimate when a new version will be ready. Some features may hit unexpected snags and delay other, possibly unrelated, features or bug fixes.

The alternative is to make releases on a steady schedule (e.g. every two weeks). This allows new features and fixes to be released promptly, but the inflexible schedule may cause short-term instability (e.g. release a feature that isn't 100% baked).

Right now, I'm leaning towards the second option. The reasoning is that it will increase testing (catch bugs and bad APIs earlier) and quicken development (at most 2 weeks latency between feature and release). This will almost certainly need stricter development practices (e.g. keep trunk stable at all times, develop new features only in branches), which will cause pain initially, but possibly increase quality later on.

What do you think about this? Do you find a steady release schedule desirable or would you prefer fewer but more feature-full releases? Have you used either of these on your own projects? How did it work out?


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
djk's picture

I am on the release early and release often side of the fence, we release our framework on a 3-4 week schedule.

We have between 5 and 10 developers working on our various software projects at any point in time, the 3-4 week schedule on the framework lets the upstream developers get access to the new/fixed/refactored functionality several times over their longer release schedule.

kanato's picture

I use the first option with AgateLib, but I keep thinking that I should try to switch to the second. But with that project I am still modifying the API fairly heavily so I am not sure if the second approach is as good in that scenario.

It might be good to do like linux distributions, and have stable releases and testing releases. I don't really know how they decide which is which, but maybe we could have a testing and stable trunk, and the testing is released every 4 weeks, and then features are independently merged into the stable trunk after they have been in testing for two releases or so.

objarni's picture

Ubuntu releases it's operating system once every half year.

That is one of the great things about that system - it is predictable.

So I'm for the new ideas Fiddler. I'm thinking "dont count features, count days".

Maybe a poll?

oyvindra's picture

Predictability = good

Inertia's picture

It certainly makes sense to release more often than currently, maybe all we need is to be less eager about the number of features that justify a version increment and simply let 1 feature or a couple of gremlins be enough. Not sure if deadlines help at all, under time pressure there is need for discussion about using the given time efficiently. That time might be better spent working on something useful.

@djk Your project is closed source? I.e. users cannot get work-in-progress version from svn?

the Fiddler's picture

It seems there's a desire for more steady / frequent releases. Maybe we can try that for a while and see how it works out.

I am hoping that making a release every x weeks will actually reduce time pressure (i.e. simply take a snapshot of the current code-base, no need to try and push features in if they are not ready). I also kinda like the idea of a set schedule, it's something I haven't tried before.

Another relevant question: how many of you use the bleeding edge from SVN? Do you prefer working with the latest code, or do you like working with baked code?

djk's picture

Inertia, our framework (TurksHead) is under the LGPL v2. We currently are trying to find a solution to expose the internal TFS repository to either GoggleCode or SourceForge with the minimum amount of loss of change history and make the IT security people happy.

Today we deliver a CD from the TFS repository to about half a dozen other development teams outside of our company, however integrating changes back in is tough.

We believe that moving to TFS 2008 and the latest version of sharepoint will allow us to make it work so to speak, the new hardware to support this is just starting to arrive and we have an experienced webservice developer in-house who has good handle on the issues.

TurksHead is an engineering smart product model for the design of marine vessels. We do have a closed source commercial tool (Orca3d) that is a plugin to Rhino that makes use of the framework. In the future we will have other applications built on TurksHead that are released as GPL/LGPL to perform various hydrodynamic performance predictions of marine vessels.

The TurksHead framework is on the 3-4 week schedule and the Orca3d product was just released. Orca3d is scheduled for a quarterly release schedule. The other groups are on completely independent schedules some follow the 3-4 weeks of the framework and at least one group is looking for yearly refreshes of the framework for thier projects.

Mincus's picture

I think a faster release schedule is desirable, but 2 weeks might be a little too quick between releases.
I say this because quite a few of the bugs that crop up are from people using the download from the site and they often get the response that it's fixed in the SVN.
With the current release schedule it's hard to predict when those fixes will be moved to the main release.

I would say 6-8 weeks is a nice in-between value, but it would depend largely on whatever time frame Fiddler (and other contributors) are most comfortable with.

objarni's picture

I prefer the baked versions, I have seldom downloaded the source OpenTK from SVN.

I agree with Mincus on 2 weeks being just a little too narrow, I'd say somwhere between a month and two months. I think that is mostly up to you Fiddler because it is you who decide what goes into the the baked version and not (code review) - and that is some extra work beside the ordinary development cycle of adding features/fixing bugs.