You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Matt Hogstrom <ma...@hogstrom.org> on 2006/06/11 21:09:23 UTC
Thoughts about what a release is
I think one of the significant frustrations I've had with getting Geronimo released is a lack of
common understanding about several items.
I am listing the ones off the top of my head (in no particular order).
*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.
So, our 1.1 that we are currently release doesn't fit the above model as very little new content was
added. The Plugins is probably the most significant feature but based on where it is at today I'd
say its more of a tech preview in terms of readiness and number of plugins available for
consumption. It really should have been 1.0.1. IIRC the reason we made it 1.1 is that so much of
the internal plumbing changed (I guess as well as the schema design) that it didn't make sense as a
1.0.1.
With that said, for 1.1.1 I am interested in fixing things like error messages that are not too
helpful, applying outstanding patches that address usability improvements (like asking are yu sure
you want to delete that) as well as improve our performance in the CMP realm where we are way
behind. The performance improvements are not destructive and are (architecturally) fairly simple to
enable. However, based on Alan's comments in another e-mail perhaps not appropriate.
With that I think we need to decide if the next turn of the crank for Geronimo is really 1.2
(incremental improvement) or 2.0 significant change, new significant features, etc.
Thoughts?
Re: Thoughts about what a release is
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 <li...@toolazydogs.com> 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
Posted by Donald Woods <dr...@yahoo.com>.
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 <li...@toolazydogs.com> 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
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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
Posted by Donald Woods <dr...@yahoo.com>.
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 <li...@toolazydogs.com> 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
Posted by Sachin Patel <sp...@gmail.com>.
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 <li...@toolazydogs.com> 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
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 <dr...@yahoo.com> 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 <li...@toolazydogs.com> 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
Posted by Hiram Chirino <hi...@hiramchirino.com>.
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 <dr...@yahoo.com> 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 <li...@toolazydogs.com> 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
Posted by Donald Woods <dr...@yahoo.com>.
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 <li...@toolazydogs.com> 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
Posted by Matt Hogstrom <ma...@hogstrom.org>.
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 <li...@toolazydogs.com> 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
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On 6/11/06, Alan D. Cabrera <li...@toolazydogs.com> 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
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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
Posted by Dain Sundstrom <da...@iq80.com>.
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
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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
Posted by Dain Sundstrom <da...@iq80.com>.
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 <li...@toolazydogs.com> 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
Posted by Dain Sundstrom <da...@iq80.com>.
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
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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
Posted by David Blevins <da...@visi.com>.
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
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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
Posted by Matt Hogstrom <ma...@hogstrom.org>.
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
Posted by David Blevins <da...@visi.com>.
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
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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 <li...@toolazydogs.com> 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
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <li...@toolazydogs.com> 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
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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
Posted by Stefan Arentz <st...@gmail.com>.
On 6/11/06, Matt Hogstrom <ma...@hogstrom.org> 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.