Callisto Coordinated Maintenance

What?

The 10 Callisto Projects have agreed to do two coordinated maintenance releases.

The first one was in the fall (September 29, 2006, which is fall in the Northern hemisphere, but spring in the Southern hemisphere), and the second in the winter (February 16, 2007, which is winter in the Northern hemisphere, but summer in the Southern hemisphere).

As with the Callisto Coordinated Release, this too is a voluntary coordination of the projects involved, with as few rules, policies, and procedures as possible, leaving each project to release their own maintenance whenever they need or want to (can you believe there have been three already!). But Callisto maintenance will offer a predictable time and place when all will be 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 whenever 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 days (or daze, as the case may be) 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.

When?

As for the planned schedule, here's a rough, proposed one:

1/5 - most teams should have identified what they will attempt to fix for Callisto Winter Maintenance

2/1 - release candidates available for testing.

2/12 - zips and update site files ready to start the mirror process

2/16 - Callisto Winter Maintenance available.

Conference calls

• Thursday, January 18 9am PT, noon ET (minutes)
  • Discuss which bugs are going to be fixed by each project and what impacts those will have on other projects
  • Discuss the build process we will use including the update site
• Thursday, February 1 9am PT, noon ET
  • Brief call to check on progress
• Thursday, February 8 9am PT, noon ET
  • Slightly longer call to verify no conflicts so far
• Thursday, February 15 9am PT, noon ET
  • Go-no-go decision meeting, followed by Callisto Winter Maintenance Release

613.287.8000 or 866.362.7064 passcode 874551#

How?

Besides preparing their own project update sites, as before, there are a couple of "best practices" teams will have to be careful of.

1. Plugin versions IDs should normally only update in the third (service) position if they were changed.
2. Plugin versions IDs should not change at all if they did not change at all.
3. 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.
4. The end-result on the update site is to have both Callisto Initial Release available and Callisto Maintenance release 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.
   1. 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 ever 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.)

You can take a look at the

• WTP [1]
• Eclipse [2]
• BIRT [3]
• TPTP [4]
• DTP [5]
• GMF [6]
• VE [7]
• EMF [8]
• EMFT [9]

The Wiki Plea

As always, please feel free to correct or add to this wiki page. Or, start a discussion on the talk page.

Thanks all,

David williams.us.ibm.com 04:51, 11 August 2006 (EDT)