Callisto Coordinated Maintenance
The 10 Callisto Projects have agreed to do two coordinated maintenance releases.
The first one in the fall (9/29/2006), and the second in the winder (approximately first of February, 2007).
As with the Callisto Coordinated Release, this too is a voluntary coordination of the projects involved, with as a few rules, policies, and procedures as possible. Leaving each project to release their own maintenance when ever they need or want to (can you believe there has been three already!) but, Callisto maintenance will offer a predictable time and place that all will up to date.
And, to emphasize, Callisto maintenance itself will not be anything "new" that users or adopters could not get from elsewhere ... its just that there will be a point in time (e.g. 9/29) that all the fixes will be available from the same place.
Each project can provide maintenance when ever they like, on their own, in their own "home" update sites. If current users, after that point, "search for updates to currently installed features" then those users will get those fixes .. they do not have to wait for Callisto.
What the Callisto coordination will do, is get all the teams focused on the same point in time to make sure they get things finished up, and well tested (with other Callisto projects) on the same schedule. Then, during the final daze of maintenance, we will put all the maintenance on the Callisto site. The biggest advantage to having the common update site at that point, is so that if new users come to the site, they will easily get the latest versions. Otherwise, they'd install once, then "search for updates to currently installed features" to get all the latest versions. Much easier to install once.
As for the planned schedule, here's a rough, proposed one:
- 8/15 most teams should have identified what they will attempt to fix for Callisto Fall Maintenance
- 9/15 release candidates available for testing.
- 9/27 zips and update site files ready to start the mirror process
- 9/29 Callisto Fall Maintenace available.
Besides preparing their own project update sites, as before, there are a couple of "best practices" teams will have to be careful of.
- . Plugin versions IDs should normally only update in the third (service) position if they were changed.
- . Plugin versions IDs should not change at all if they did not change at all.
- . Feature version IDs should change according to its "most greatly changed" contained plugin, so if none of the contained plugins changed, then the feature version should not change either.
- . The end-result on the update site is to have both Callisto Initial Release available and Callisto Fall Maintenace available. Normally, users will want "the latest", but, its only good practice to allow them to install (or, more likely re-install) the previous version After all, in rare cases, they may like that previous version better, for some reason. Or, want to check some behavior, etc. to report a bug.
- . Note: the mechanics of doing this "multiple versions" is that teams update their feature*.xml file in Callisto build-tools by adding features and versions to their lists ... don't just replace the old version with the new one.
What, exactly, is fixed?
What exactly is fixed in a maintenance release? Just bugs. Teams rarely add "new features" or "new API" to a maintenance release, but they may occasionally. Most teams are pretty conservative about changing things, due to the every present danger of regressions. But, I'd still expect the final number to be between 500 and 1000 bugs. (Again, each project decides their own criteria and needs.)
The Wiki Plea
As always, please feel to correct or add to this wiki page. Or, start a discussion on the talk page.
David williams.us.ibm.com 04:51, 11 August 2006 (EDT)