Re: Release and Version Philosophy [Discussion]
APR's guidelines look very reasonable to me. Adopting them (perhaps with a few minor tweaks or clarifications) would have the added benefit of aligning Geronimo with an existing Apache standard/practice, which I think end users will certainly appreciate. Best wishes, Paul On 1/15/06, Brian McCallister [EMAIL PROTECTED] wrote: APR's versioning guidelines are an awfully good practice, in myexperience.http://apr.apache.org/versioning.html -Brian
Re: Release and Version Philosophy [Discussion]
Matt Hogstrom wrote: First, I see there is a structure for versioning like: v.r.m[.f] where: v = Version r = Release m = modification f = fix (optional) Another minor point - these names are a bit unwieldy and it is difficult to say: 1.0 is the version of a Version release. 1.0.1 is the version of a modification release. 1.1 is the version of a Release release. So how about M.f.u[.p] where: M = major f = feature u = update p = patch (optional) Thus we have: 1.0 is the version of a Major release 1.0.1 is the version of an update release 1.1 is the version of a feature release. cheers
Re: Release and Version Philosophy [Discussion]
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?
Re: Release and Version Philosophy [Discussion]
Matt Hogstrom wrote, On 1/14/2006 9:02 PM: 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? I see this as a two dimensional problem. How do we communicate to our end users what can be expected and how we go about fulfilling those expectations during our engineering effort. The initial touch point is version numbers. I think that end users are only concerned with how things are compatible when they look at version numbers, not the process that was used to meet those compatibility expectations. I think that you've mixed the two together, which is why you have a Release and Modification. I'm thinking: - merge R and M, having that granularity seems confusing and I cannot think of a compelling scenario that we would need to support to justify it. - remove the last statement of Release; *all* code released, be it V, R, M, or F, by Geronimo needs to go through a formal release candidates. The nomenclature that I would use would be: Major.Minor.Patch(-RC#)+ I'm fleshing out my ideas at http://opensource.atlassian.com/confluence/oss/x/Wgs Regards, Alan
Re: Release and Version Philosophy [Discussion]
APR's versioning guidelines are an awfully good practice, in my experience. http://apr.apache.org/versioning.html -Brian On Jan 15, 2006, at 10:42 AM, Alan D. Cabrera wrote: Matt Hogstrom wrote, On 1/14/2006 9:02 PM: 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? I see this as a two dimensional problem. How do we communicate to our end users what can be expected and how we go about fulfilling those expectations during our engineering effort. The initial touch point is version numbers. I think that end users are only concerned with how things are compatible when they look at version numbers, not the process that was used to meet those compatibility expectations. I think that you've mixed the two together, which is why you have a Release and Modification. I'm thinking: - merge R and M, having that granularity seems confusing and I cannot think of a compelling scenario that we would need to support to justify it. - remove the last statement of Release; *all* code released, be it V, R, M, or F, by Geronimo needs to go through a formal release candidates. The nomenclature that I would use would be: Major.Minor.Patch(-RC#)+ I'm fleshing out my ideas at http://opensource.atlassian.com/confluence/oss/x/Wgs Regards, Alan
Release and Version Philosophy [Discussion]
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?
Re: Release and Version Philosophy [Discussion]
To me the only important requirements in release numbers are that they should tell the user: 1. Whether the release is backward compatible. 2. Whether it's a stable build vs. unstable. I would rather not to have to learn the various meanings of digits 1-N. It seems like it would make it more transparent, but actually it makes it less transparent because people need to think (!). As far as patching goes, there will be people who want bug fix 5 but not 6,7,8 because they think that any change other than they one they want will cause them to stay past five o'clock, but I think that those are the kind of the people that must be made to pay for commercial support. On Sun, 15 Jan 2006, 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?
