Re: Thoughts about what a release is
Donald Woods wrote: I have to agree with Matt - wrapping the container as a GBean and then letting the container do its job is the least obtrusive for existing users. I'm not sure where Matt's message implies this. Why must we turn everything into a GBean? We already make things difficult for existing Tomcat users and developers who want to move their skills and apps over to Geronimo. Why should we do the same for every other service we add into the server? I, and people who started XBean, feel the same way. IIUC, this will be cleaned up in 1.2. Regards, Alan -Donald Matt Hogstrom wrote: Not sure if this is already captured. What do folks think about leaving the modules as independent pieces with their own version numbers and the geronimo_version is just the aggregate release to users? I expect this would make out life more difficult but I haven't found the single version number to rule all modules all that easy either. Also, it would be nice that if a module hadn't changed then it stays static and is a good indicator of where the activity is. Thoughts? Hiram Chirino wrote: On 6/11/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: X.Y.z: patch release - bug fixes X.y:minor release - bug fixes and compatible enhancements x: major release - major enhancements, and incompatible changes I am very much against placing anything but patches in the .z releases. Let me explain why. When we make a minor release we basically branch the X.y release for the purposes of releasing patches. Any changes to this branch, e.g. patches, must also be immediately applied to the trunk. If we make any enhancements to this branch, we must also immediately apply the same enhancement to that branch. This adds significant more risk that bug patching but more importantly when we fall into the trap of putting minor enhancements into a patch release, we remove the most serious impetus to getting the minor release done and out the door. +1. This allows us to time box the bug fix releases. If we can get into the groove of doing regular x.y.z releases (at like 1 a month intervals), then I think that also reduces the pressure on needing to make the x.y releases perfect. I think we sometimes delay our x.y releases because we are aiming for perfection. The only problem with the above is that it does not solve the problem of being able to time box the x.y release. The since dev branch of the x.y release could have multiple new features at different levels of completion it's hard to stabilize at any given time. Do you guys consider this a problem? I like Dain's suggestion of splitting up the modules. In theory in progress work being done separately versioned project should not hold up the time boxed release of a Geronimo x.y. Geronimo would just release with the previous stable version. In practice, even for independently versioned projects like ActiveMQ, Geronimo will hold up it's releases to get new releases from ActiveMQ. This is bad if you want to time box a release. Another thought that might help Geronimo be able to stay on a time box release cycle is making more use of 'development' branches. We could encourage develops to work on new features in development branches that get merged in once the feature is fully working. The down side to this is that it may not be obvious to other developers what work is going on where. Or perhaps we need to do a a combination of independent versioned modules where most of the work happens, and then having small development branches of the main Geronimo module that holds the integration code that enables the new features. So then then development branches are used to do integration testing with in progress features and they are merged in to trunk once the feature is done and all integration testing is completed.
Re: Thoughts about what a release is
Sorry, Hiram. I'm not following. Can you explain in greater detail? Regards, Alan Hiram Chirino wrote: Well, for one, you could do a release of geronimo at any time since should stay stable as long as it does not move to SNAPSHOT dependencies. Regards, Hiram On 6/15/06, Donald Woods <[EMAIL PROTECTED]> wrote: Seems like a nightmare to me - 1) By not updating all the modules with every release, aren't we going to have problems with different module levels using different external dependency levels, like Log4J, Howl, Xerces, Commons-*, ... which will cause runtime exceptions when multiple levels of the same JAR are on the same classpath? 2) We already have difficulties in keeping the dependency version numbers in sync across Geronimo, Specs, Devtools, Daytrader, OpenEJB and TranQL It would only get worse to manage if we had to keep track of 18 Spec versions and 45 module versions! What would it really buy us, besides more work and more complicated builds? -Donald Matt Hogstrom wrote: > Not sure if this is already captured. > > What do folks think about leaving the modules as independent pieces with > their own version numbers and the geronimo_version is just the aggregate > release to users? I expect this would make out life more difficult but > I haven't found the single version number to rule all modules all that > easy either. > > Also, it would be nice that if a module hadn't changed then it stays > static and is a good indicator of where the activity is. > > Thoughts? > > Hiram Chirino wrote: > >> On 6/11/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: >> >>> >>> X.Y.z: patch release - bug fixes >>> X.y:minor release - bug fixes and compatible enhancements >>> x: major release - major enhancements, and incompatible changes >>> >>> >>> I am very much against placing anything but patches in the .z releases. >>> Let me explain why. When we make a minor release we basically branch >>> the X.y release for the purposes of releasing patches. Any changes to >>> this branch, e.g. patches, must also be immediately applied to the >>> trunk. If we make any enhancements to this branch, we must also >>> immediately apply the same enhancement to that branch. This adds >>> significant more risk that bug patching but more importantly when we >>> fall into the trap of putting minor enhancements into a patch release, >>> we remove the most serious impetus to getting the minor release done and >>> out the door. >>> >> >> +1. This allows us to time box the bug fix releases. If we can get >> into the groove of doing regular x.y.z releases (at like 1 a month >> intervals), then I think that also reduces the pressure on needing to >> make the x.y releases perfect. I think we sometimes delay our x.y >> releases because we are aiming for perfection. >> >> The only problem with the above is that it does not solve the problem >> of being able to time box the x.y release. The since dev branch of >> the x.y release could have multiple new features at different levels >> of completion it's hard to stabilize at any given time. Do you guys >> consider this a problem? >> >> I like Dain's suggestion of splitting up the modules. In theory in >> progress work being done separately versioned project should not hold >> up the time boxed release of a Geronimo x.y. Geronimo would just >> release with the previous stable version. In practice, even for >> independently versioned projects like ActiveMQ, Geronimo will hold up >> it's releases to get new releases from ActiveMQ. This is bad if you >> want to time box a release. >> >> Another thought that might help Geronimo be able to stay on a time box >> release cycle is making more use of 'development' branches. We could >> encourage develops to work on new features in development branches >> that get merged in once the feature is fully working. The down side >> to this is that it may not be obvious to other developers what work is >> going on where. >> >> Or perhaps we need to do a a combination of independent versioned >> modules where most of the work happens, and then having small >> development branches of the main Geronimo module that holds the >> integration code that enables the new features. So then then >> development branches are used to do integration testing with in >> progress features and they are merged in to trunk once the feature is >> done and all integration testing is completed. >> >> > >
Re: Thoughts about what a release is
Matt Hogstrom wrote: Not sure if this is already captured. What do folks think about leaving the modules as independent pieces with their own version numbers and the geronimo_version is just the aggregate release to users? I expect this would make out life more difficult but I haven't found the single version number to rule all modules all that easy either. Also, it would be nice that if a module hadn't changed then it stays static and is a good indicator of where the activity is. Thoughts? Too many inter-dependencies for this to fly plus, it does not fix any of the issues that we've discussed; IIUC. Regards, Alan
Re: Thoughts about what a release is
Aren't the configuration plans (CARs) already an implementation of that idea? Matt, are you suggesting something like we group a Config/Plugin and its module dependencies into a separate subproject that will be built with its own version number, like say a geronimo-axis subproject that includes the axis and axis-deployer modules into a single config/CAR that could be used to add everything needed for Axis to a server assembly? If so, then that makes more sense than having independent version numbers for every module and config we build Also, wouldn't this idea require that we update all of the modules and configs as part of 1.2 to not use specific dependency versions? -Donald Sachin Patel wrote: I think it would make life more difficult managing so many versions and the compatibility between those version, however I think this would be beneifical for updating the server at a more granulized level. Another approach is to break out the server into components (multiple modules making up a component identified by a groupId) and each group Id could have its own version. On Jun 15, 2006, at 12:34 AM, Matt Hogstrom wrote: Not sure if this is already captured. What do folks think about leaving the modules as independent pieces with their own version numbers and the geronimo_version is just the aggregate release to users? I expect this would make out life more difficult but I haven't found the single version number to rule all modules all that easy either. Also, it would be nice that if a module hadn't changed then it stays static and is a good indicator of where the activity is. Thoughts? Hiram Chirino wrote: On 6/11/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: X.Y.z: patch release - bug fixes X.y:minor release - bug fixes and compatible enhancements x: major release - major enhancements, and incompatible changes I am very much against placing anything but patches in the .z releases. Let me explain why. When we make a minor release we basically branch the X.y release for the purposes of releasing patches. Any changes to this branch, e.g. patches, must also be immediately applied to the trunk. If we make any enhancements to this branch, we must also immediately apply the same enhancement to that branch. This adds significant more risk that bug patching but more importantly when we fall into the trap of putting minor enhancements into a patch release, we remove the most serious impetus to getting the minor release done and out the door. +1. This allows us to time box the bug fix releases. If we can get into the groove of doing regular x.y.z releases (at like 1 a month intervals), then I think that also reduces the pressure on needing to make the x.y releases perfect. I think we sometimes delay our x.y releases because we are aiming for perfection. The only problem with the above is that it does not solve the problem of being able to time box the x.y release. The since dev branch of the x.y release could have multiple new features at different levels of completion it's hard to stabilize at any given time. Do you guys consider this a problem? I like Dain's suggestion of splitting up the modules. In theory in progress work being done separately versioned project should not hold up the time boxed release of a Geronimo x.y. Geronimo would just release with the previous stable version. In practice, even for independently versioned projects like ActiveMQ, Geronimo will hold up it's releases to get new releases from ActiveMQ. This is bad if you want to time box a release. Another thought that might help Geronimo be able to stay on a time box release cycle is making more use of 'development' branches. We could encourage develops to work on new features in development branches that get merged in once the feature is fully working. The down side to this is that it may not be obvious to other developers what work is going on where. Or perhaps we need to do a a combination of independent versioned modules where most of the work happens, and then having small development branches of the main Geronimo module that holds the integration code that enables the new features. So then then development branches are used to do integration testing with in progress features and they are merged in to trunk once the feature is done and all integration testing is completed. -sachin smime.p7s Description: S/MIME Cryptographic Signature
Re: Thoughts about what a release is
I think it would make life more difficult managing so many versions and the compatibility between those version, however I think this would be beneifical for updating the server at a more granulized level. Another approach is to break out the server into components (multiple modules making up a component identified by a groupId) and each group Id could have its own version. On Jun 15, 2006, at 12:34 AM, Matt Hogstrom wrote: Not sure if this is already captured. What do folks think about leaving the modules as independent pieces with their own version numbers and the geronimo_version is just the aggregate release to users? I expect this would make out life more difficult but I haven't found the single version number to rule all modules all that easy either. Also, it would be nice that if a module hadn't changed then it stays static and is a good indicator of where the activity is. Thoughts? Hiram Chirino wrote: On 6/11/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: X.Y.z: patch release - bug fixes X.y:minor release - bug fixes and compatible enhancements x: major release - major enhancements, and incompatible changes I am very much against placing anything but patches in the .z releases. Let me explain why. When we make a minor release we basically branch the X.y release for the purposes of releasing patches. Any changes to this branch, e.g. patches, must also be immediately applied to the trunk. If we make any enhancements to this branch, we must also immediately apply the same enhancement to that branch. This adds significant more risk that bug patching but more importantly when we fall into the trap of putting minor enhancements into a patch release, we remove the most serious impetus to getting the minor release done and out the door. +1. This allows us to time box the bug fix releases. If we can get into the groove of doing regular x.y.z releases (at like 1 a month intervals), then I think that also reduces the pressure on needing to make the x.y releases perfect. I think we sometimes delay our x.y releases because we are aiming for perfection. The only problem with the above is that it does not solve the problem of being able to time box the x.y release. The since dev branch of the x.y release could have multiple new features at different levels of completion it's hard to stabilize at any given time. Do you guys consider this a problem? I like Dain's suggestion of splitting up the modules. In theory in progress work being done separately versioned project should not hold up the time boxed release of a Geronimo x.y. Geronimo would just release with the previous stable version. In practice, even for independently versioned projects like ActiveMQ, Geronimo will hold up it's releases to get new releases from ActiveMQ. This is bad if you want to time box a release. Another thought that might help Geronimo be able to stay on a time box release cycle is making more use of 'development' branches. We could encourage develops to work on new features in development branches that get merged in once the feature is fully working. The down side to this is that it may not be obvious to other developers what work is going on where. Or perhaps we need to do a a combination of independent versioned modules where most of the work happens, and then having small development branches of the main Geronimo module that holds the integration code that enables the new features. So then then development branches are used to do integration testing with in progress features and they are merged in to trunk once the feature is done and all integration testing is completed. -sachin
Re: Thoughts about what a release is
Well, for one, you could do a release of geronimo at any time since should stay stable as long as it does not move to SNAPSHOT dependencies. Regards, Hiram On 6/15/06, Donald Woods <[EMAIL PROTECTED]> wrote: Seems like a nightmare to me - 1) By not updating all the modules with every release, aren't we going to have problems with different module levels using different external dependency levels, like Log4J, Howl, Xerces, Commons-*, ... which will cause runtime exceptions when multiple levels of the same JAR are on the same classpath? 2) We already have difficulties in keeping the dependency version numbers in sync across Geronimo, Specs, Devtools, Daytrader, OpenEJB and TranQL It would only get worse to manage if we had to keep track of 18 Spec versions and 45 module versions! What would it really buy us, besides more work and more complicated builds? -Donald Matt Hogstrom wrote: > Not sure if this is already captured. > > What do folks think about leaving the modules as independent pieces with > their own version numbers and the geronimo_version is just the aggregate > release to users? I expect this would make out life more difficult but > I haven't found the single version number to rule all modules all that > easy either. > > Also, it would be nice that if a module hadn't changed then it stays > static and is a good indicator of where the activity is. > > Thoughts? > > Hiram Chirino wrote: > >> On 6/11/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: >> >>> >>> X.Y.z: patch release - bug fixes >>> X.y:minor release - bug fixes and compatible enhancements >>> x: major release - major enhancements, and incompatible changes >>> >>> >>> I am very much against placing anything but patches in the .z releases. >>> Let me explain why. When we make a minor release we basically branch >>> the X.y release for the purposes of releasing patches. Any changes to >>> this branch, e.g. patches, must also be immediately applied to the >>> trunk. If we make any enhancements to this branch, we must also >>> immediately apply the same enhancement to that branch. This adds >>> significant more risk that bug patching but more importantly when we >>> fall into the trap of putting minor enhancements into a patch release, >>> we remove the most serious impetus to getting the minor release done and >>> out the door. >>> >> >> +1. This allows us to time box the bug fix releases. If we can get >> into the groove of doing regular x.y.z releases (at like 1 a month >> intervals), then I think that also reduces the pressure on needing to >> make the x.y releases perfect. I think we sometimes delay our x.y >> releases because we are aiming for perfection. >> >> The only problem with the above is that it does not solve the problem >> of being able to time box the x.y release. The since dev branch of >> the x.y release could have multiple new features at different levels >> of completion it's hard to stabilize at any given time. Do you guys >> consider this a problem? >> >> I like Dain's suggestion of splitting up the modules. In theory in >> progress work being done separately versioned project should not hold >> up the time boxed release of a Geronimo x.y. Geronimo would just >> release with the previous stable version. In practice, even for >> independently versioned projects like ActiveMQ, Geronimo will hold up >> it's releases to get new releases from ActiveMQ. This is bad if you >> want to time box a release. >> >> Another thought that might help Geronimo be able to stay on a time box >> release cycle is making more use of 'development' branches. We could >> encourage develops to work on new features in development branches >> that get merged in once the feature is fully working. The down side >> to this is that it may not be obvious to other developers what work is >> going on where. >> >> Or perhaps we need to do a a combination of independent versioned >> modules where most of the work happens, and then having small >> development branches of the main Geronimo module that holds the >> integration code that enables the new features. So then then >> development branches are used to do integration testing with in >> progress features and they are merged in to trunk once the feature is >> done and all integration testing is completed. >> >> > > -- Regards, Hiram Blog: http://hiramchirino.com
Re: Thoughts about what a release is
I have to agree with Matt - wrapping the container as a GBean and then letting the container do its job is the least obtrusive for existing users. Why must we turn everything into a GBean? We already make things difficult for existing Tomcat users and developers who want to move their skills and apps over to Geronimo. Why should we do the same for every other service we add into the server? -Donald Matt Hogstrom wrote: Not sure if this is already captured. What do folks think about leaving the modules as independent pieces with their own version numbers and the geronimo_version is just the aggregate release to users? I expect this would make out life more difficult but I haven't found the single version number to rule all modules all that easy either. Also, it would be nice that if a module hadn't changed then it stays static and is a good indicator of where the activity is. Thoughts? Hiram Chirino wrote: On 6/11/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: X.Y.z: patch release - bug fixes X.y:minor release - bug fixes and compatible enhancements x: major release - major enhancements, and incompatible changes I am very much against placing anything but patches in the .z releases. Let me explain why. When we make a minor release we basically branch the X.y release for the purposes of releasing patches. Any changes to this branch, e.g. patches, must also be immediately applied to the trunk. If we make any enhancements to this branch, we must also immediately apply the same enhancement to that branch. This adds significant more risk that bug patching but more importantly when we fall into the trap of putting minor enhancements into a patch release, we remove the most serious impetus to getting the minor release done and out the door. +1. This allows us to time box the bug fix releases. If we can get into the groove of doing regular x.y.z releases (at like 1 a month intervals), then I think that also reduces the pressure on needing to make the x.y releases perfect. I think we sometimes delay our x.y releases because we are aiming for perfection. The only problem with the above is that it does not solve the problem of being able to time box the x.y release. The since dev branch of the x.y release could have multiple new features at different levels of completion it's hard to stabilize at any given time. Do you guys consider this a problem? I like Dain's suggestion of splitting up the modules. In theory in progress work being done separately versioned project should not hold up the time boxed release of a Geronimo x.y. Geronimo would just release with the previous stable version. In practice, even for independently versioned projects like ActiveMQ, Geronimo will hold up it's releases to get new releases from ActiveMQ. This is bad if you want to time box a release. Another thought that might help Geronimo be able to stay on a time box release cycle is making more use of 'development' branches. We could encourage develops to work on new features in development branches that get merged in once the feature is fully working. The down side to this is that it may not be obvious to other developers what work is going on where. Or perhaps we need to do a a combination of independent versioned modules where most of the work happens, and then having small development branches of the main Geronimo module that holds the integration code that enables the new features. So then then development branches are used to do integration testing with in progress features and they are merged in to trunk once the feature is done and all integration testing is completed. smime.p7s Description: S/MIME Cryptographic Signature
Re: Thoughts about what a release is
Seems like a nightmare to me - 1) By not updating all the modules with every release, aren't we going to have problems with different module levels using different external dependency levels, like Log4J, Howl, Xerces, Commons-*, ... which will cause runtime exceptions when multiple levels of the same JAR are on the same classpath? 2) We already have difficulties in keeping the dependency version numbers in sync across Geronimo, Specs, Devtools, Daytrader, OpenEJB and TranQL It would only get worse to manage if we had to keep track of 18 Spec versions and 45 module versions! What would it really buy us, besides more work and more complicated builds? -Donald Matt Hogstrom wrote: Not sure if this is already captured. What do folks think about leaving the modules as independent pieces with their own version numbers and the geronimo_version is just the aggregate release to users? I expect this would make out life more difficult but I haven't found the single version number to rule all modules all that easy either. Also, it would be nice that if a module hadn't changed then it stays static and is a good indicator of where the activity is. Thoughts? Hiram Chirino wrote: On 6/11/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: X.Y.z: patch release - bug fixes X.y:minor release - bug fixes and compatible enhancements x: major release - major enhancements, and incompatible changes I am very much against placing anything but patches in the .z releases. Let me explain why. When we make a minor release we basically branch the X.y release for the purposes of releasing patches. Any changes to this branch, e.g. patches, must also be immediately applied to the trunk. If we make any enhancements to this branch, we must also immediately apply the same enhancement to that branch. This adds significant more risk that bug patching but more importantly when we fall into the trap of putting minor enhancements into a patch release, we remove the most serious impetus to getting the minor release done and out the door. +1. This allows us to time box the bug fix releases. If we can get into the groove of doing regular x.y.z releases (at like 1 a month intervals), then I think that also reduces the pressure on needing to make the x.y releases perfect. I think we sometimes delay our x.y releases because we are aiming for perfection. The only problem with the above is that it does not solve the problem of being able to time box the x.y release. The since dev branch of the x.y release could have multiple new features at different levels of completion it's hard to stabilize at any given time. Do you guys consider this a problem? I like Dain's suggestion of splitting up the modules. In theory in progress work being done separately versioned project should not hold up the time boxed release of a Geronimo x.y. Geronimo would just release with the previous stable version. In practice, even for independently versioned projects like ActiveMQ, Geronimo will hold up it's releases to get new releases from ActiveMQ. This is bad if you want to time box a release. Another thought that might help Geronimo be able to stay on a time box release cycle is making more use of 'development' branches. We could encourage develops to work on new features in development branches that get merged in once the feature is fully working. The down side to this is that it may not be obvious to other developers what work is going on where. Or perhaps we need to do a a combination of independent versioned modules where most of the work happens, and then having small development branches of the main Geronimo module that holds the integration code that enables the new features. So then then development branches are used to do integration testing with in progress features and they are merged in to trunk once the feature is done and all integration testing is completed. smime.p7s Description: S/MIME Cryptographic Signature
Re: Thoughts about what a release is
Not sure if this is already captured. What do folks think about leaving the modules as independent pieces with their own version numbers and the geronimo_version is just the aggregate release to users? I expect this would make out life more difficult but I haven't found the single version number to rule all modules all that easy either. Also, it would be nice that if a module hadn't changed then it stays static and is a good indicator of where the activity is. Thoughts? Hiram Chirino wrote: On 6/11/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: X.Y.z: patch release - bug fixes X.y:minor release - bug fixes and compatible enhancements x: major release - major enhancements, and incompatible changes I am very much against placing anything but patches in the .z releases. Let me explain why. When we make a minor release we basically branch the X.y release for the purposes of releasing patches. Any changes to this branch, e.g. patches, must also be immediately applied to the trunk. If we make any enhancements to this branch, we must also immediately apply the same enhancement to that branch. This adds significant more risk that bug patching but more importantly when we fall into the trap of putting minor enhancements into a patch release, we remove the most serious impetus to getting the minor release done and out the door. +1. This allows us to time box the bug fix releases. If we can get into the groove of doing regular x.y.z releases (at like 1 a month intervals), then I think that also reduces the pressure on needing to make the x.y releases perfect. I think we sometimes delay our x.y releases because we are aiming for perfection. The only problem with the above is that it does not solve the problem of being able to time box the x.y release. The since dev branch of the x.y release could have multiple new features at different levels of completion it's hard to stabilize at any given time. Do you guys consider this a problem? I like Dain's suggestion of splitting up the modules. In theory in progress work being done separately versioned project should not hold up the time boxed release of a Geronimo x.y. Geronimo would just release with the previous stable version. In practice, even for independently versioned projects like ActiveMQ, Geronimo will hold up it's releases to get new releases from ActiveMQ. This is bad if you want to time box a release. Another thought that might help Geronimo be able to stay on a time box release cycle is making more use of 'development' branches. We could encourage develops to work on new features in development branches that get merged in once the feature is fully working. The down side to this is that it may not be obvious to other developers what work is going on where. Or perhaps we need to do a a combination of independent versioned modules where most of the work happens, and then having small development branches of the main Geronimo module that holds the integration code that enables the new features. So then then development branches are used to do integration testing with in progress features and they are merged in to trunk once the feature is done and all integration testing is completed.
Re: Thoughts about what a release is
On 6/11/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: X.Y.z: patch release - bug fixes X.y:minor release - bug fixes and compatible enhancements x: major release - major enhancements, and incompatible changes I am very much against placing anything but patches in the .z releases. Let me explain why. When we make a minor release we basically branch the X.y release for the purposes of releasing patches. Any changes to this branch, e.g. patches, must also be immediately applied to the trunk. If we make any enhancements to this branch, we must also immediately apply the same enhancement to that branch. This adds significant more risk that bug patching but more importantly when we fall into the trap of putting minor enhancements into a patch release, we remove the most serious impetus to getting the minor release done and out the door. +1. This allows us to time box the bug fix releases. If we can get into the groove of doing regular x.y.z releases (at like 1 a month intervals), then I think that also reduces the pressure on needing to make the x.y releases perfect. I think we sometimes delay our x.y releases because we are aiming for perfection. The only problem with the above is that it does not solve the problem of being able to time box the x.y release. The since dev branch of the x.y release could have multiple new features at different levels of completion it's hard to stabilize at any given time. Do you guys consider this a problem? I like Dain's suggestion of splitting up the modules. In theory in progress work being done separately versioned project should not hold up the time boxed release of a Geronimo x.y. Geronimo would just release with the previous stable version. In practice, even for independently versioned projects like ActiveMQ, Geronimo will hold up it's releases to get new releases from ActiveMQ. This is bad if you want to time box a release. Another thought that might help Geronimo be able to stay on a time box release cycle is making more use of 'development' branches. We could encourage develops to work on new features in development branches that get merged in once the feature is fully working. The down side to this is that it may not be obvious to other developers what work is going on where. Or perhaps we need to do a a combination of independent versioned modules where most of the work happens, and then having small development branches of the main Geronimo module that holds the integration code that enables the new features. So then then development branches are used to do integration testing with in progress features and they are merged in to trunk once the feature is done and all integration testing is completed. -- Regards, Hiram
Re: Thoughts about what a release is
David Blevins wrote: On Jun 11, 2006, at 6:14 PM, Alan D. Cabrera wrote: Aaron Mulder wrote: I'd feel a lot better about tight restrictions on 1.1.1 if we really made 1.2 a "minor release" and put all the stuff on the plate for 1.2 into 2.0. But so long as 1.2 is a major release, then 1.1.1 needs more than hot fixes. On a related point, I'm not sure we want multiple big version releases per year. I agree with you here. The nice thing about the policy that I outlined below is that we can safely time box patch releases. As for what gets scheduled for what release, I think that it's not realistic to start by stacking a release w/ issues and hope that people will "show up" to get them done in the scheduled time frame; this only works if we are making shoes ;). With that said, time boxing is what would work best with our unique body of developers. Working within the strict interpretation of releases that I outlined below, people would schedule themselves in with concrete commitments. Bugs would not get scheduled in until someone actually picked it up and started working on it. At that time, the developer would mark what releases his changes would fix. Features would not get scheduled in until someone actually commits to doing that feature. I like this approach for most things. There will always be the need to say "x needs to be fixed to ship this release" even if no one is signed up to work on it. I just wish we'd vote or come to a consensus on items like these *before* they get assigned to a release. IMHO, having to +1 it to be added to the release means among many things you 1) saw it, 2) know about it, 3) are fully aware of what is outstanding and not yet being worked on, and 4) you agree with it. Based on our past experience over the last two releases and a couple of Milestones we all feel the urgent need to get things fixed. However, as I was clearing out 1.1 there were lots of assigned issues with relatively low overhead in applying and verifying them but the assignee was busy with other things. This is fine. IMHO JIRA's should not be assigned to a version number until there is someone that will be working on them. That way we'll end up with things people are planning on completing for a release in the release. We have had "important bugs" in JIRA (some older than two years). In short, I think we should try it David. I'm fine voting on blocks of related issues all at once to speed up the process. I think having to agree before hand on what goes in and what's required for a release will force us to talk about things earlier in the release cycle rather than later. Yes, it will also have people think about what's important for the release. One are we need to bone up on is making sure that we look at JIRAs when they come in. There are a number I moved to 1.1.1 and plan on integrating where people did the work and created a patch. It will help us grow the community a lot if they see we are attentive to their contributions and that the contributions actually get in. If the patch won't work, then we need to give them feedback on what will work. I think this is an ethic change for us. -David
Re: Thoughts about what a release is
David Blevins wrote: On Jun 12, 2006, at 12:15 PM, Alan D. Cabrera wrote: David Blevins wrote: On Jun 11, 2006, at 6:14 PM, Alan D. Cabrera wrote: Aaron Mulder wrote: I'd feel a lot better about tight restrictions on 1.1.1 if we really made 1.2 a "minor release" and put all the stuff on the plate for 1.2 into 2.0. But so long as 1.2 is a major release, then 1.1.1 needs more than hot fixes. On a related point, I'm not sure we want multiple big version releases per year. I agree with you here. The nice thing about the policy that I outlined below is that we can safely time box patch releases. As for what gets scheduled for what release, I think that it's not realistic to start by stacking a release w/ issues and hope that people will "show up" to get them done in the scheduled time frame; this only works if we are making shoes ;). With that said, time boxing is what would work best with our unique body of developers. Working within the strict interpretation of releases that I outlined below, people would schedule themselves in with concrete commitments. Bugs would not get scheduled in until someone actually picked it up and started working on it. At that time, the developer would mark what releases his changes would fix. Features would not get scheduled in until someone actually commits to doing that feature. I like this approach for most things. There will always be the need to say "x needs to be fixed to ship this release" even if no one is signed up to work on it. I just wish we'd vote or come to a consensus on items like these *before* they get assigned to a release. IMHO, having to +1 it to be added to the release means among many things you 1) saw it, 2) know about it, 3) are fully aware of what is outstanding and not yet being worked on, and 4) you agree with it. We are a group of individuals who work on a voluntary basis. Assigning issues to a release amounts to wishful thinking; just look at the version ping pong that Matt and Aaron play for our releases. Sure... seems you are making my point for me, am I missing something? And to be clear, I am only talking about unassigned issues; things we as a group think should be done but don't yet have an owner. I just want to see some discussion and agreement on these kinds of items. RTC is already in place for things actually done for a release. I am talking about those as well. There's no point in assigning a version number to an unassigned issue if no one has committed to doing the work. Maybe that's not what you're advocating. Regards, Alan
Re: Thoughts about what a release is
On Jun 12, 2006, at 12:15 PM, Alan D. Cabrera wrote: David Blevins wrote: On Jun 11, 2006, at 6:14 PM, Alan D. Cabrera wrote: Aaron Mulder wrote: I'd feel a lot better about tight restrictions on 1.1.1 if we really made 1.2 a "minor release" and put all the stuff on the plate for 1.2 into 2.0. But so long as 1.2 is a major release, then 1.1.1 needs more than hot fixes. On a related point, I'm not sure we want multiple big version releases per year. I agree with you here. The nice thing about the policy that I outlined below is that we can safely time box patch releases. As for what gets scheduled for what release, I think that it's not realistic to start by stacking a release w/ issues and hope that people will "show up" to get them done in the scheduled time frame; this only works if we are making shoes ;). With that said, time boxing is what would work best with our unique body of developers. Working within the strict interpretation of releases that I outlined below, people would schedule themselves in with concrete commitments. Bugs would not get scheduled in until someone actually picked it up and started working on it. At that time, the developer would mark what releases his changes would fix. Features would not get scheduled in until someone actually commits to doing that feature. I like this approach for most things. There will always be the need to say "x needs to be fixed to ship this release" even if no one is signed up to work on it. I just wish we'd vote or come to a consensus on items like these *before* they get assigned to a release. IMHO, having to +1 it to be added to the release means among many things you 1) saw it, 2) know about it, 3) are fully aware of what is outstanding and not yet being worked on, and 4) you agree with it. We are a group of individuals who work on a voluntary basis. Assigning issues to a release amounts to wishful thinking; just look at the version ping pong that Matt and Aaron play for our releases. Sure... seems you are making my point for me, am I missing something? And to be clear, I am only talking about unassigned issues; things we as a group think should be done but don't yet have an owner. I just want to see some discussion and agreement on these kinds of items. RTC is already in place for things actually done for a release. I'd at least like to try it and see how it plays out. We can drop it and go back to jira ping-pong or try something else if it doesn't work out well. -David
Re: Thoughts about what a release is
Dain Sundstrom wrote: On Jun 12, 2006, at 12:09 PM, Alan D. Cabrera wrote: Splitting the product into separate lines would not cause time tested, industry standard, principals to not apply to apply to those new proposed product lines. I would feel just as strongly about the pieces as I would the whole. I agree with you, but it would mean that each line would progress at its own speed. I would expect stuff like the console to have several major revisions for the next few years, where stuff like the transaction processing part of the server would have a major release every 18 months. A great reason to break up the product. Regards, Alan
Re: Thoughts about what a release is
On Jun 12, 2006, at 12:09 PM, Alan D. Cabrera wrote: Dain Sundstrom wrote: I am a bit torn here, because I agree with both of you depending on which code we are talking about. Geronimo is a large project and I think we will be doing ourselves a disservice if we attempt to treat all of the code the same. For example, I think Alan's comments apply best to the core transaction processing parts of geronimo, and I think think Aaron's comments apply best to non- critical parts of the server like the console and tooling. I would be upset if someone tried to add a new feature to the core server in a micro release, but if they say added a new command to the cli or a new portlet, I wouldn't be upset at all. Can we find a compromise where critical code moves more conservatively and non-critical code gets more liberal rules? If not, I think we should start talking about how to divide up the code base into independently versioned released components. This will take a lot of effort in architecture and organization in our team. I'd rather not do it at this time, but maybe the time has come sooner that I wanted. Core stuff is more important to you because, well, that's what you work on. What you consider "fluff" stuff may be critical to others. Alan, that was not my point. There is stuff that applications use directly (e.g., the tx mgr, ejb container, servlet engine, etc) and then there is stuff like the console and sample applications. If my tx mgr, breaks I'm screwed where as if the console breaks, it isn't as bad, and if a sample app breaks. Not all code has the same constraints. Splitting the product into separate lines would not cause time tested, industry standard, principals to not apply to apply to those new proposed product lines. I would feel just as strongly about the pieces as I would the whole. I agree with you, but it would mean that each line would progress at its own speed. I would expect stuff like the console to have several major revisions for the next few years, where stuff like the transaction processing part of the server would have a major release every 18 months. Anyway, I've made my point, and I will be happy with what ever the project agrees on as long as everyone is equally happy (or unhappy). -dain
Re: Thoughts about what a release is
David Blevins wrote: On Jun 11, 2006, at 6:14 PM, Alan D. Cabrera wrote: Aaron Mulder wrote: I'd feel a lot better about tight restrictions on 1.1.1 if we really made 1.2 a "minor release" and put all the stuff on the plate for 1.2 into 2.0. But so long as 1.2 is a major release, then 1.1.1 needs more than hot fixes. On a related point, I'm not sure we want multiple big version releases per year. I agree with you here. The nice thing about the policy that I outlined below is that we can safely time box patch releases. As for what gets scheduled for what release, I think that it's not realistic to start by stacking a release w/ issues and hope that people will "show up" to get them done in the scheduled time frame; this only works if we are making shoes ;). With that said, time boxing is what would work best with our unique body of developers. Working within the strict interpretation of releases that I outlined below, people would schedule themselves in with concrete commitments. Bugs would not get scheduled in until someone actually picked it up and started working on it. At that time, the developer would mark what releases his changes would fix. Features would not get scheduled in until someone actually commits to doing that feature. I like this approach for most things. There will always be the need to say "x needs to be fixed to ship this release" even if no one is signed up to work on it. I just wish we'd vote or come to a consensus on items like these *before* they get assigned to a release. IMHO, having to +1 it to be added to the release means among many things you 1) saw it, 2) know about it, 3) are fully aware of what is outstanding and not yet being worked on, and 4) you agree with it. We are a group of individuals who work on a voluntary basis. Assigning issues to a release amounts to wishful thinking; just look at the version ping pong that Matt and Aaron play for our releases. IMO, voting can easily be accomplished w/ Jira voting. I'm fine voting on blocks of related issues all at once to speed up the process. Not sure that's necessary if we use Jira voting. I think having to agree before hand on what goes in and what's required for a release will force us to talk about things earlier in the release cycle rather than later. So would lobbying for votes for your favorite issues. Regards, Alan
Re: Thoughts about what a release is
Dain Sundstrom wrote: I am a bit torn here, because I agree with both of you depending on which code we are talking about. Geronimo is a large project and I think we will be doing ourselves a disservice if we attempt to treat all of the code the same. For example, I think Alan's comments apply best to the core transaction processing parts of geronimo, and I think think Aaron's comments apply best to non-critical parts of the server like the console and tooling. I would be upset if someone tried to add a new feature to the core server in a micro release, but if they say added a new command to the cli or a new portlet, I wouldn't be upset at all. Can we find a compromise where critical code moves more conservatively and non-critical code gets more liberal rules? If not, I think we should start talking about how to divide up the code base into independently versioned released components. This will take a lot of effort in architecture and organization in our team. I'd rather not do it at this time, but maybe the time has come sooner that I wanted. Core stuff is more important to you because, well, that's what you work on. What you consider "fluff" stuff may be critical to others. Splitting the product into separate lines would not cause time tested, industry standard, principals to not apply to apply to those new proposed product lines. I would feel just as strongly about the pieces as I would the whole. Regards, Alan
Re: Thoughts about what a release is
On Jun 12, 2006, at 11:46 AM, David Blevins wrote: On Jun 11, 2006, at 6:14 PM, Alan D. Cabrera wrote: Features would not get scheduled in until someone actually commits to doing that feature. I like this approach for most things. There will always be the need to say "x needs to be fixed to ship this release" even if no one is signed up to work on it. I just wish we'd vote or come to a consensus on items like these *before* they get assigned to a release. IMHO, having to +1 it to be added to the release means among many things you 1) saw it, 2) know about it, 3) are fully aware of what is outstanding and not yet being worked on, and 4) you agree with it. I'm fine voting on blocks of related issues all at once to speed up the process. I think having to agree before hand on what goes in and what's required for a release will force us to talk about things earlier in the release cycle rather than later. Cool idea. I think we should try it out. +1 to vote on scheduling a feature in a release -dain
Re: Thoughts about what a release is
On Jun 11, 2006, at 6:14 PM, Alan D. Cabrera wrote: Aaron Mulder wrote: I'd feel a lot better about tight restrictions on 1.1.1 if we really made 1.2 a "minor release" and put all the stuff on the plate for 1.2 into 2.0. But so long as 1.2 is a major release, then 1.1.1 needs more than hot fixes. On a related point, I'm not sure we want multiple big version releases per year. I agree with you here. The nice thing about the policy that I outlined below is that we can safely time box patch releases. As for what gets scheduled for what release, I think that it's not realistic to start by stacking a release w/ issues and hope that people will "show up" to get them done in the scheduled time frame; this only works if we are making shoes ;). With that said, time boxing is what would work best with our unique body of developers. Working within the strict interpretation of releases that I outlined below, people would schedule themselves in with concrete commitments. Bugs would not get scheduled in until someone actually picked it up and started working on it. At that time, the developer would mark what releases his changes would fix. Features would not get scheduled in until someone actually commits to doing that feature. I like this approach for most things. There will always be the need to say "x needs to be fixed to ship this release" even if no one is signed up to work on it. I just wish we'd vote or come to a consensus on items like these *before* they get assigned to a release. IMHO, having to +1 it to be added to the release means among many things you 1) saw it, 2) know about it, 3) are fully aware of what is outstanding and not yet being worked on, and 4) you agree with it. I'm fine voting on blocks of related issues all at once to speed up the process. I think having to agree before hand on what goes in and what's required for a release will force us to talk about things earlier in the release cycle rather than later. -David
Re: Thoughts about what a release is
I am a bit torn here, because I agree with both of you depending on which code we are talking about. Geronimo is a large project and I think we will be doing ourselves a disservice if we attempt to treat all of the code the same. For example, I think Alan's comments apply best to the core transaction processing parts of geronimo, and I think think Aaron's comments apply best to non-critical parts of the server like the console and tooling. I would be upset if someone tried to add a new feature to the core server in a micro release, but if they say added a new command to the cli or a new portlet, I wouldn't be upset at all. Can we find a compromise where critical code moves more conservatively and non-critical code gets more liberal rules? If not, I think we should start talking about how to divide up the code base into independently versioned released components. This will take a lot of effort in architecture and organization in our team. I'd rather not do it at this time, but maybe the time has come sooner that I wanted. -dain On Jun 11, 2006, at 6:14 PM, Alan D. Cabrera wrote: Aaron Mulder wrote: I'd feel a lot better about tight restrictions on 1.1.1 if we really made 1.2 a "minor release" and put all the stuff on the plate for 1.2 into 2.0. But so long as 1.2 is a major release, then 1.1.1 needs more than hot fixes. On a related point, I'm not sure we want multiple big version releases per year. I agree with you here. The nice thing about the policy that I outlined below is that we can safely time box patch releases. As for what gets scheduled for what release, I think that it's not realistic to start by stacking a release w/ issues and hope that people will "show up" to get them done in the scheduled time frame; this only works if we are making shoes ;). With that said, time boxing is what would work best with our unique body of developers. Working within the strict interpretation of releases that I outlined below, people would schedule themselves in with concrete commitments. Bugs would not get scheduled in until someone actually picked it up and started working on it. At that time, the developer would mark what releases his changes would fix. Features would not get scheduled in until someone actually commits to doing that feature. The larger the feature, the stricter the requirements are for milestones. Regards, Alan On 6/11/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: Matt Hogstrom wrote: > *What constitutes a release?* > Speaking from my IBM WebSphere days (just as a point of reference for > discussion and not specifically a recommendation) we generally > differentiated products based on Versions and Releases. Versions were > significant new content and function which might be defined as a new > J2EE specification implementation, significant new function > (clustering improvements might fall in this category), etc. > > Releases were less dramatic and more incremental in nature. They > could include performance improvements, new features that were not > disruptive to previous releases (such as improved CMP persistence > options, etc.) or perhaps even a JDK Version upgrade from 1.4 to 1.5 > for instance. Releases could also include what we referred to as tech > previews. These were items that we wanted people to have a chance to > start using but it wasn't fully baked yet. However, we did not want > to wait a whole version release to put it in the hands of the users. > > So for notational usefulness. We saw a version number break down like > v.r.m where V is the major version number, R was the release number > and M was a modification level. > > Modification levels could include new features of a limited nature as > described above. One was simply aware of how it would impact the > users in terms of determining appropriateness. > > Thoughts? I prefer the more conventional nomenclature of major, minor, and patch. The explain this I will grossly plagiarize what Noel Bergman posted on the James list. X.Y.z: patch release - bug fixes X.y:minor release - bug fixes and compatible enhancements x: major release - major enhancements, and incompatible changes I am very much against placing anything but patches in the .z releases. Let me explain why. When we make a minor release we basically branch the X.y release for the purposes of releasing patches. Any changes to this branch, e.g. patches, must also be immediately applied to the trunk. If we make any enhancements to this branch, we must also immediately apply the same enhancement to that branch. This adds significant more risk that bug patching but more importantly when we fall into the trap of putting minor enhancements into a patch release, we remove the most serious impetus to getting the minor release done and out the door. Let us make an honest assessment of ourselves based on past out beh
Re: Thoughts about what a release is
Aaron Mulder wrote: I'd feel a lot better about tight restrictions on 1.1.1 if we really made 1.2 a "minor release" and put all the stuff on the plate for 1.2 into 2.0. But so long as 1.2 is a major release, then 1.1.1 needs more than hot fixes. On a related point, I'm not sure we want multiple big version releases per year. I agree with you here. The nice thing about the policy that I outlined below is that we can safely time box patch releases. As for what gets scheduled for what release, I think that it's not realistic to start by stacking a release w/ issues and hope that people will "show up" to get them done in the scheduled time frame; this only works if we are making shoes ;). With that said, time boxing is what would work best with our unique body of developers. Working within the strict interpretation of releases that I outlined below, people would schedule themselves in with concrete commitments. Bugs would not get scheduled in until someone actually picked it up and started working on it. At that time, the developer would mark what releases his changes would fix. Features would not get scheduled in until someone actually commits to doing that feature. The larger the feature, the stricter the requirements are for milestones. Regards, Alan On 6/11/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: Matt Hogstrom wrote: > *What constitutes a release?* > Speaking from my IBM WebSphere days (just as a point of reference for > discussion and not specifically a recommendation) we generally > differentiated products based on Versions and Releases. Versions were > significant new content and function which might be defined as a new > J2EE specification implementation, significant new function > (clustering improvements might fall in this category), etc. > > Releases were less dramatic and more incremental in nature. They > could include performance improvements, new features that were not > disruptive to previous releases (such as improved CMP persistence > options, etc.) or perhaps even a JDK Version upgrade from 1.4 to 1.5 > for instance. Releases could also include what we referred to as tech > previews. These were items that we wanted people to have a chance to > start using but it wasn't fully baked yet. However, we did not want > to wait a whole version release to put it in the hands of the users. > > So for notational usefulness. We saw a version number break down like > v.r.m where V is the major version number, R was the release number > and M was a modification level. > > Modification levels could include new features of a limited nature as > described above. One was simply aware of how it would impact the > users in terms of determining appropriateness. > > Thoughts? I prefer the more conventional nomenclature of major, minor, and patch. The explain this I will grossly plagiarize what Noel Bergman posted on the James list. X.Y.z: patch release - bug fixes X.y:minor release - bug fixes and compatible enhancements x: major release - major enhancements, and incompatible changes I am very much against placing anything but patches in the .z releases. Let me explain why. When we make a minor release we basically branch the X.y release for the purposes of releasing patches. Any changes to this branch, e.g. patches, must also be immediately applied to the trunk. If we make any enhancements to this branch, we must also immediately apply the same enhancement to that branch. This adds significant more risk that bug patching but more importantly when we fall into the trap of putting minor enhancements into a patch release, we remove the most serious impetus to getting the minor release done and out the door. Let us make an honest assessment of ourselves based on past out behavior, we do not have the discipline that it takes to put only minor enhancements into a patch release. Regards, Alan
Re: Thoughts about what a release is
I'd feel a lot better about tight restrictions on 1.1.1 if we really made 1.2 a "minor release" and put all the stuff on the plate for 1.2 into 2.0. But so long as 1.2 is a major release, then 1.1.1 needs more than hot fixes. On a related point, I'm not sure we want multiple big version releases per year. Thanks, Aaron On 6/11/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: Matt Hogstrom wrote: > *What constitutes a release?* > Speaking from my IBM WebSphere days (just as a point of reference for > discussion and not specifically a recommendation) we generally > differentiated products based on Versions and Releases. Versions were > significant new content and function which might be defined as a new > J2EE specification implementation, significant new function > (clustering improvements might fall in this category), etc. > > Releases were less dramatic and more incremental in nature. They > could include performance improvements, new features that were not > disruptive to previous releases (such as improved CMP persistence > options, etc.) or perhaps even a JDK Version upgrade from 1.4 to 1.5 > for instance. Releases could also include what we referred to as tech > previews. These were items that we wanted people to have a chance to > start using but it wasn't fully baked yet. However, we did not want > to wait a whole version release to put it in the hands of the users. > > So for notational usefulness. We saw a version number break down like > v.r.m where V is the major version number, R was the release number > and M was a modification level. > > Modification levels could include new features of a limited nature as > described above. One was simply aware of how it would impact the > users in terms of determining appropriateness. > > Thoughts? I prefer the more conventional nomenclature of major, minor, and patch. The explain this I will grossly plagiarize what Noel Bergman posted on the James list. X.Y.z: patch release - bug fixes X.y:minor release - bug fixes and compatible enhancements x: major release - major enhancements, and incompatible changes I am very much against placing anything but patches in the .z releases. Let me explain why. When we make a minor release we basically branch the X.y release for the purposes of releasing patches. Any changes to this branch, e.g. patches, must also be immediately applied to the trunk. If we make any enhancements to this branch, we must also immediately apply the same enhancement to that branch. This adds significant more risk that bug patching but more importantly when we fall into the trap of putting minor enhancements into a patch release, we remove the most serious impetus to getting the minor release done and out the door. Let us make an honest assessment of ourselves based on past out behavior, we do not have the discipline that it takes to put only minor enhancements into a patch release. Regards, Alan
Re: Thoughts about what a release is
Alan D. Cabrera wrote: Matt Hogstrom wrote: *What constitutes a release?* Speaking from my IBM WebSphere days (just as a point of reference for discussion and not specifically a recommendation) we generally differentiated products based on Versions and Releases. Versions were significant new content and function which might be defined as a new J2EE specification implementation, significant new function (clustering improvements might fall in this category), etc. Releases were less dramatic and more incremental in nature. They could include performance improvements, new features that were not disruptive to previous releases (such as improved CMP persistence options, etc.) or perhaps even a JDK Version upgrade from 1.4 to 1.5 for instance. Releases could also include what we referred to as tech previews. These were items that we wanted people to have a chance to start using but it wasn't fully baked yet. However, we did not want to wait a whole version release to put it in the hands of the users. So for notational usefulness. We saw a version number break down like v.r.m where V is the major version number, R was the release number and M was a modification level. Modification levels could include new features of a limited nature as described above. One was simply aware of how it would impact the users in terms of determining appropriateness. Thoughts? Ugh. I should take time to edit before I send. I prefer the more conventional nomenclature of major, minor, and patch. To explain this I will grossly plagiarize what Noel Bergman had posted on the James list. X.Y.z: patch release - bug fixes X.y:minor release - bug fixes and compatible enhancements x: major release - major enhancements, and incompatible changes My personal thoughts are: I am very much against placing anything but patches in the .z releases. Let me explain why. When we make a minor release we basically branch the X.y release for the purposes of releasing patches. Any changes to this branch, i.e. patches, must also be immediately applied to the trunk. If we make any enhancements to this branch we must also immediately apply the same enhancement to the trunk. This adds significant more risk than bug patching but, more importantly, when we fall into the trap of putting minor enhancements into a patch release, we remove the most serious impetus to getting the minor release done and out the door. Let us make an honest assessment of ourselves based on past out behavior; we do not have the discipline that it takes to put only minor enhancements into a patch release. Regards, Alan
Re: Thoughts about what a release is
Matt Hogstrom wrote: *What constitutes a release?* Speaking from my IBM WebSphere days (just as a point of reference for discussion and not specifically a recommendation) we generally differentiated products based on Versions and Releases. Versions were significant new content and function which might be defined as a new J2EE specification implementation, significant new function (clustering improvements might fall in this category), etc. Releases were less dramatic and more incremental in nature. They could include performance improvements, new features that were not disruptive to previous releases (such as improved CMP persistence options, etc.) or perhaps even a JDK Version upgrade from 1.4 to 1.5 for instance. Releases could also include what we referred to as tech previews. These were items that we wanted people to have a chance to start using but it wasn't fully baked yet. However, we did not want to wait a whole version release to put it in the hands of the users. So for notational usefulness. We saw a version number break down like v.r.m where V is the major version number, R was the release number and M was a modification level. Modification levels could include new features of a limited nature as described above. One was simply aware of how it would impact the users in terms of determining appropriateness. Thoughts? I prefer the more conventional nomenclature of major, minor, and patch. The explain this I will grossly plagiarize what Noel Bergman posted on the James list. X.Y.z: patch release - bug fixes X.y:minor release - bug fixes and compatible enhancements x: major release - major enhancements, and incompatible changes I am very much against placing anything but patches in the .z releases. Let me explain why. When we make a minor release we basically branch the X.y release for the purposes of releasing patches. Any changes to this branch, e.g. patches, must also be immediately applied to the trunk. If we make any enhancements to this branch, we must also immediately apply the same enhancement to that branch. This adds significant more risk that bug patching but more importantly when we fall into the trap of putting minor enhancements into a patch release, we remove the most serious impetus to getting the minor release done and out the door. Let us make an honest assessment of ourselves based on past out behavior, we do not have the discipline that it takes to put only minor enhancements into a patch release. Regards, Alan
Re: Thoughts about what a release is
On 6/11/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Thoughts? Ahhh the version number game. Perception is reality :-) When I see a headline about Geronimo 1.2, I will probably think 'pfff still no EJB3 support, what are those slow coders doing all the time?!'. However, if it would see a 'Geronimo 2.0' headline then I would be immediately curious and check it out in detail because I know good stuff has happened in a major release. People will generally also think the product is more mature. (Which is is of course, a version number increment will just confirm that feeling more) S.
