Matt, good initiative!
I would like to see the philosophy include a bit of process about how a version is create. For example a believe a fix release should definitely be created by the application of a few carefully QA'd patches to an existing released branch of the code. More over, I would like to argue that modification versions, like 1.0.1 should be created in the same way. Ie, they should not be created by a wholesale copy from trunk and then a stabilazation period. I would argue that anything that is to difficult to QA as a few patches would thus self exlcude itself from a modification release. Plus if done without a copy from trunk, all modules would not need to synchronize their development cycles for a modification release like 1.0.1 A Version or Release release should be made from a copy from trunk followed by a stabilazation period. cheers Matt Hogstrom wrote: > I've seen several posts about the upcoming 1.0.x release and 1.1 and 2.0 > etc. lately and I think its great that we're having these discussions. > > I'd like to use this thread to aggregate people's thoughts about this > topic in a single thread for reference and clarification as we make > forward progress. So I'd like to clarify some terminology (at least > post what the terms mean to me) so we can make some meaningful plans for > our various efforts going forward. > > This is a strawman so don't get too revved up. I think we need to > balance between structure and fluidity and I'm not sure exactly how to > do that; input welcome. > > First, I see there is a structure for versioning like: > > v.r.m[.f] where: > > v = Version > r = Release > m = modification > f = fix (optional) > > Version > ------- > - Represents a significant set of improvements in Geronimo and a > definite milestone for our users. > - New features are introduced that may break compatibility and require > users to have to modify their existing applications that ran on previous > Versions. (Although we should strive to not force them to change > immediately but rather provide something like a V-1 or -2 compatibility > story. -2 Would be excellent but that might be too optimistic given the > rate of change. > - Things like JEE 5 would be found in a version change. > - Goes through a formal Release Candidate process for user feedback and > has broad coverage in terms of announcement. (Not just the Dev List) > - Release Candidates look something like Geronimo-2.0-RC1/2/3 etc. > > Release > ------- > - Can include significant new features / improvements. > - Should not break existing applications (lot's of traffic from users > saying something worked on M5 but doesn't on 1.0) > - Includes bug fixes and the like. > - It would be hard to justify moving to JEE 5 based on a release change. > - Has broad announcement > - Does not go through formal Release Candidate Process but does make > interim release attempts based on a dated binary release (ala > Geronimo-jetty-1.1-rc20060315) > > Modification > ------------ > - Incremental release that builds on the goals of the V.R its based on. > - Can include new features > - Cannot disrupt existing application deployments > - Includes multiple bug fixes > > Fix > --- > - Focused release that addresses a specific critical bug. > - We're no where near this now but it would be nice to release specific > bug fixes and not whole server releases. > - An example of this would be something like a fix to the recent problem > Jetty uncovered related to security. A fix in this context would be a > simple packaging change to get the new Jetty Jar into the build and > wouldn't require a whole new server to be spun off. > > Thoughts? >
