Forum OpenACS Development: 6.0 Release Schedule Proposal

Posted by Lars Pind on
Yup, it's no typo.

Just to get a feel for what 3-month release cycles would feel like, I thought I'd throw this out now already.

- Feature freeze for 6.0 would be 1 January 2004.

- Release date for 6.0 would be 1 February 2004.

That gives us about two months from 5.0 is released until feature freeze for 6.0.

That also means that late december is the time to make sure we've purged the bug-tracker for submitted patches.

And that gives us the opportunity to start thinking about what's realistic to get into 6.0 already today.

I expect us to be contributing some workflow enhancements, and I sincerely hope we can find either time or funding to do some serious bug-tracker improvements. Also, I hope to be able to contribute to the CMS efforts going on. Plus more general UI work, hopefully this time moving a step deeper into the packages themselves.

Does the idea of targeting these dates sound fun?

To me, the prospect of 3-month release cycles is very encouraging, because it means we'll get in the habit of releasing, which means cleaning out bugs and stabilizing the code base, and it gives the users of OpenACS something to work with, when they decide which version to use, it gives them the incentive to stay close to the releases, and it tells them exactly when they need to have their bugs filed and patches submitted if they want them to go into the next release.



Posted by Talli Somekh on
While I think that it's cool that this plan would get us to v14 by 2006, perhaps we should consider the next release to be 5.1 rather than 6.0?

The version numbers are sort of irrelevant, though. I heard of one project that added a sig fig of pi for each version release...


Posted by Malte Sussdorff on
First of all, Talli is right. Call it 5.1 ;)

Okay, three months release cycles sound nice, but we'd have to see how it works out in practise, as the release managers have other projects (paid for) to attend as well. On the other hand, it would make it easier for people to say, yeah, it's okay, I will wait til the next version to put my code in, it's only three month away.

Concerning the Version 6.0. I guess we should branch a version 6.0 if we want to make changes again, that affect the whole system (like internationlization and noquote have done).

Other than that, let's go for it, branch version 5.1 on 1st of January with a focus to fix all outstanding bugs by first of February for a release. Would be great if this actually happens ;).

Concerning the scope you mention, don't overstretch yourself and get too ambitious. I think work-flow enhancements would be nice, a better bug-tracker if funding is there, as well (we are using it for AIESEC bug tracking with ton's of users posting bugs, requests and tasks, so we are more than willing to hand over improvements and ideas). But CMS or Project Manager would be too far a stretch in my opinion.

Posted by Lars Pind on
... and I heard of a company which does 4 releases per year, and name them 11, 12, 13, 14 (in 2001), 21, 22, 23, 24 (in 2002), 31, 32, 33, 34 (in 2003), etc.

I don't have strong opinions on version numbers, but I don't see any reason to be too humble in setting them, either.

Malte, thanks for the words of caution. Note that I didn't put a scope on any of the things mentioned. Could be a half-hour contribution in each area. Ooh, nice, then I could go to Buenos Aires and hang out on the beaches the rest of the time. 😉


Posted by Carl Coryell-Martin on
We seem to do about one major point release per year and a minor point release every quarter.  I am partial to saving the major point releases for big events that may affect many systems or will encourage developers to change their practices and minor point releases for significant improvements.

Other than that note, I dig the three month release cycle.

Posted by marc spitzer on
I like the major/minor idea.  Where a major release may include any of the following:

1: need to upgrade db
2: need to upgrade aol server, not including minor/security patches
3: major changes in the db scheema
4: major changes to the api's, not including new apis
5: at least once a year, just to keep the ball rolling

I hate suprises, 4 to 5 work, 5 to 6 not much work, 6 to 7 not much work, etc.  How do I quickly tell the difference and explain it to management/customers?  If on the other hand I can point to 5.x to 6.x(bigger job) vs 5.x to 5.y it makes life easier.