Re: [emft-dev] Reminder: It's Ganymede M4 release week!

["Nick Boldt" <codeslave@xxxxxxxxxx>]

I've already promoted 0.8.0M4 builds for both Net4j and CDO on Dec. 17th.
Now I've added them to the three wiki pages [1], [2], [3].
Since Net4j does only depend on the Platform I've sent it to the +1 band, ok?

Perfect, thanks.

I've not so far published them to the Ganymede update site because I was unsure about the version that I should use.
I used 0.8.0 for the Eclipse 3.3/EMF 2.3 stuff and until now I had no breaking changes in my code although it appears to become desirable soon.
When I build/promote and promote my projects for Eclipse 3.4/EMF 2.4 (Ganymede) should I use 0.9.0?
But I can't change the manifest versions withou branching, right?
Currently it's a bit confusing because I publish 0.8.0 labels with 3.4/2.4 dependencies...

PLAN A (BAD -- extra effort, broken release notes):

Since you never released a 0.8.0R (final GA) build but plan to do so at some point (perhaps after Eclipse 3.3.2 is done in late February?) then I'd branch and start working on 0.9.0 (for Eclipse 3.4) and 0.8.0 (for Eclipse 3.3.x) in parallel.

However, branching in the middle of a stream (before an R) will screw up the release notes generator, so here's a better approach...

PLAN B (GOOD -- some extra paperwork but project consistency):

Before you actually start using Eclipse 3.4 code (and your code base therefore requires it and won't run on 3.3 anymore), do your 0.8.0 release review [1], and publish your 0.8.0R build (built with Eclipse 3.3.1.1). Then, branch to "R0_8_maintenance". When you commit a change to either HEAD or R0_8_maintenance, update your feature.xml's and manifest.mf 's appropriately (moving to 0.9.0 or 0.8.1, respectively).

[1] http://divby0.blogspot.com/2007/10/release-review-today.html

Going forward you'll be able to contribute your 0.9.0 builds to Ganymede, and complete your 0.8.1 development in time for (or some time after) Eclipse 3.3.2's release in February.

PLAN C (SIMPLER -- no support for 3.3.x):

If you don't need to support running on Eclipse 
3.3.x, then just keep on truckin' as is -- 0.8.0 will be the Ganymede stream release.

TIMING

As to the timing... if you don't want to bother with a 0.8.0/0.8.1/0.9.0 set of builds and would rather go with just 
0.8.0/0.9.0, then delay making any 3.4-dependent changes until 
after Eclipse 3.3.2 is released on Feb 29, and cut your 0.8.0 R build then. (You still need to do a Release Review, however.) Without needing to branch, you can then move forward renumbering HEAD plugins/features to 
0.9.0 (as above in Plan B). In the event you ever need to do a 0.8.1 build, you can branch retroactively.

---

For those playing along at home, the recommended approach is that you follow the release schedule of Eclipse and EMF, releasing once a year (or more, if you need maintenance updates), and upversioning every year as well. So, for new components now at 
0.7.0, you'll need to do an annual Release Review in June/July, perhaps as a combined "All of EMFT" review. Your versioning should align with a specific EMF/Eclipse version (2.4/3.4) so as to avoid the confusion Eike is experiencing now. FWIW, the 'new platform breaking changes' tend to occur between September and May, so if you're aligned with EMF you can usually do your 
0.7.0 (in June), your 0.7.1 (in September), and then branch for 0.8.0's development for the upcoming year. You could also branch right after 0.7.0, but so little breaking code appears in the platform over the summer that it's usually safe (and takes less effort) to have a 
x.y.1 and x.(y+1).0 combined HEAD branch which runs on both EMF/Eclipse versions (you do builds for both streams, sourced from the same CVS branch but using different dependencies). The major benefit here is that fixes done in BOTH streams are committed once to HEAD instead of twice (once per branch). It's backporting without the extra effort! ;-)

Nick