You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dain Sundstrom <da...@iq80.com> on 2006/09/05 22:40:14 UTC
Release Early, Release Often
According to our STATUS file, our last feature release (1.1) was on
2006-06-26 which is about 2.5 months ago. I'm not sure exactly what
we have in trunk right now, but I'd guess we most likely have enough
to do a release right now. I'm going to spend a few hours today
browsing the JIRAs and SVN logs and compile a list of the features we
have in trunk right now. Anyways, I'll let you know what I find and
we can figure out what we want to do.
Thanks,
-dain
Re: Release Early, Release Often
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Good point.. it might not even be legally possible to do none
certified releases. I'm really hoping that we can.
Perhaps we add big "J2EE Certified" and "NOT Certified" logos next to
the releases and clear text in the README regarding the certification
status of a release.
I'm just suggesting this since I don't think release early and release
often is possible if every release has to be certified.
On 9/7/06, Matt Hogstrom <ma...@hogstrom.org> wrote:
> How would you handle J2EE certification then? I don't know the rules around it but I want to be
> careful about confusing users.
>
> I'm all for release early and often (tried to do that with 1.1.1 but these pesky security issues and
> other problems pop up). I think getting a weekly drop available will be a significant help. We
> tried that in the past (I think Blevins spearheaded new feature Wednesdays).
>
> If we got that going first (and not considering releases) I think that would be a huge help. I'm
> happy to assist when 1.1.1 gets out the door.
>
>
>
> Jason Dillon wrote:
> > Something tells me that we are gonna end up with a 6mo+ release cycle
> > (with additional month just to make the release)... and that if we are
> > lucky.
> >
> > So far I'm not hearing anyone else signing the "Release Early, Release
> > Often" tune.
> >
> > I'd stop thinking about 1.2 as JEE5 or whatever thing that is gonna take
> > a bunch of time to do... and just get some incremental work done and
> > push out a release.
> >
> > --jason
> >
> >
> > On Sep 7, 2006, at 7:22 AM, Matt Hogstrom wrote:
> >
> >> I think Dain said he was scouring the primordial soup of trunk to
> >> determine which level of life form would emerge. At this point if its
> >> a single cell organism then a .2 release might seem inappropriate. If
> >> its an intergalactic space traveler that can cure cancer, solve world
> >> peace and make a good pina colada then perhaps we should go to 3.0 :)
> >>
> >> Dain, how are we doing with the data mining? Seem like the natives
> >> are getting restless :-0
> >>
> >> Dave Colasurdo wrote:
> >>> Here is the wikipedia definition for Pre-Alpha, Alpha, Beta, etc..
> >>> http://en.wikipedia.org/wiki/Alpha_release
> >>> The definitions pretty much agree with my preconception of what an
> >>> Alpha would contain.
> >>> IMHO, trunk is not currently in an Alpha state and doesn't accurately
> >>> reflect the "majority of the software requirements" that will be
> >>> addressed in G1.2.
> >>> It seems that trunk is currently in a pre-alpha state and I believe
> >>> making an occasional unstable/nightly build available would allow
> >>> users/developers to get familiar with the latest and greatest
> >>> functions in trunk without giving the false impression that G1.2 is
> >>> currently in Alpha state.
> >>> Just my .02
> >>> -Dave-
> >>> Jason Dillon wrote:
> >>>> I am thinking about an 1.2-alpha release, which does not need to
> >>>> pass any tck, but can still be downloaded by folks that want to test
> >>>> their apps on the bleeding edge (with out having to build). While
> >>>> there is nothing major from a J2EE perspective in the alpha, a lot
> >>>> has changed, or will change very shortly. Here is a list with
> >>>> comments of new and upcoming stuff:
> >>>>
> >>>> ActiveMQ 4.1, is about to get committed.
> >>>>
> >>>> Derby is about to get upgraded.
> >>>>
> >>>> Log4j is about to get upgraded.
> >>>>
> >>>> Use of concurrent util is about to get changed to
> >>>> backport-concurrent-util.
> >>>>
> >>>> Lets not forget that we changed the build system, which mostly
> >>>> impacts development, but also has an impact on the configuration
> >>>> files, and plugins... new CAR m2 plugin. I think it would be really
> >>>> good to get an alpha out so that people can easily test and provide
> >>>> feedback.
> >>>>
> >>>> New m2 plugin to start/stop Geronimo, soon to have new deploy goals.
> >>>>
> >>>> A bunch of bug fixes.
> >>>>
> >>>> * * *
> >>>>
> >>>> I think that by releasing a 1.2-alpha, that we also start down the
> >>>> path of changing the perception of how quickly we release. The
> >>>> alpha can also serve to help us get some experience using the m2
> >>>> release plugin so that when it comes time for a non-alpha/beta
> >>>> release that we have confidence in the procedure... and this will
> >>>> give us time to make sure that we have the right configurations and
> >>>> setup to make a release with relative ease.
> >>>>
> >>>> Also, more of a side effect, by making a new release, it helps
> >>>> control the JIRA roadmap, right now 1.2 is filled with a bunch of
> >>>> build system related fluff and other bits...
> >>>>
> >>>> I think that we have enough changes (or soon to change in the next
> >>>> days or so) to warrant an alpha. I don't see any reason why not
> >>>> to... we don't need to spend days/weeks to ensure the TCK passes,
> >>>> because we don't need to run it. It should be sufficient to vote on
> >>>> an alpha and then cut the release, which should be easy with the
> >>>> maven release plugin, and even easier with my gpg-sign'ing mojo to
> >>>> sign and upload all artifacts.
> >>>>
> >>>> I believe that having this alpha out will benefit our community,
> >>>> showing that we are going to start releasing more often, give people
> >>>> a chance to provide feedback more often an earlier.
> >>>>
> >>>> I certainly do not expect any production customers to use this, but
> >>>> I do expect that app developers will, so they can ready their apps
> >>>> for deployment on the platform. We will clearly label this as an
> >>>> alpha release, and clear state that it has not been TCK certified.
> >>>>
> >>>> I don't see any downside to cutting a release off of trunk soonish,
> >>>> in the next week or so.
> >>>>
> >>>> --jason
> >>>>
> >>>>
> >>>> On Sep 6, 2006, at 9:13 AM, Kevan Miller wrote:
> >>>>
> >>>>>
> >>>>> On Sep 5, 2006, at 4:40 PM, Dain Sundstrom wrote:
> >>>>>
> >>>>>> According to our STATUS file, our last feature release (1.1) was
> >>>>>> on 2006-06-26 which is about 2.5 months ago. I'm not sure exactly
> >>>>>> what we have in trunk right now, but I'd guess we most likely have
> >>>>>> enough to do a release right now. I'm going to spend a few hours
> >>>>>> today browsing the JIRAs and SVN logs and compile a list of the
> >>>>>> features we have in trunk right now. Anyways, I'll let you know
> >>>>>> what I find and we can figure out what we want to do.
> >>>>>
> >>>>> I'd be interested to hear more concretely what's in Geronimo trunk,
> >>>>> OpenEJB 2.2, etc that's not in 1.1.1...
> >>>>>
> >>>>> --kevan
> >>>>
> >>>>
> >>>>
> >
> >
> >
> >
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Release Early, Release Often
Posted by Matt Hogstrom <ma...@hogstrom.org>.
How would you handle J2EE certification then? I don't know the rules around it but I want to be
careful about confusing users.
I'm all for release early and often (tried to do that with 1.1.1 but these pesky security issues and
other problems pop up). I think getting a weekly drop available will be a significant help. We
tried that in the past (I think Blevins spearheaded new feature Wednesdays).
If we got that going first (and not considering releases) I think that would be a huge help. I'm
happy to assist when 1.1.1 gets out the door.
Jason Dillon wrote:
> Something tells me that we are gonna end up with a 6mo+ release cycle
> (with additional month just to make the release)... and that if we are
> lucky.
>
> So far I'm not hearing anyone else signing the "Release Early, Release
> Often" tune.
>
> I'd stop thinking about 1.2 as JEE5 or whatever thing that is gonna take
> a bunch of time to do... and just get some incremental work done and
> push out a release.
>
> --jason
>
>
> On Sep 7, 2006, at 7:22 AM, Matt Hogstrom wrote:
>
>> I think Dain said he was scouring the primordial soup of trunk to
>> determine which level of life form would emerge. At this point if its
>> a single cell organism then a .2 release might seem inappropriate. If
>> its an intergalactic space traveler that can cure cancer, solve world
>> peace and make a good pina colada then perhaps we should go to 3.0 :)
>>
>> Dain, how are we doing with the data mining? Seem like the natives
>> are getting restless :-0
>>
>> Dave Colasurdo wrote:
>>> Here is the wikipedia definition for Pre-Alpha, Alpha, Beta, etc..
>>> http://en.wikipedia.org/wiki/Alpha_release
>>> The definitions pretty much agree with my preconception of what an
>>> Alpha would contain.
>>> IMHO, trunk is not currently in an Alpha state and doesn't accurately
>>> reflect the "majority of the software requirements" that will be
>>> addressed in G1.2.
>>> It seems that trunk is currently in a pre-alpha state and I believe
>>> making an occasional unstable/nightly build available would allow
>>> users/developers to get familiar with the latest and greatest
>>> functions in trunk without giving the false impression that G1.2 is
>>> currently in Alpha state.
>>> Just my .02
>>> -Dave-
>>> Jason Dillon wrote:
>>>> I am thinking about an 1.2-alpha release, which does not need to
>>>> pass any tck, but can still be downloaded by folks that want to test
>>>> their apps on the bleeding edge (with out having to build). While
>>>> there is nothing major from a J2EE perspective in the alpha, a lot
>>>> has changed, or will change very shortly. Here is a list with
>>>> comments of new and upcoming stuff:
>>>>
>>>> ActiveMQ 4.1, is about to get committed.
>>>>
>>>> Derby is about to get upgraded.
>>>>
>>>> Log4j is about to get upgraded.
>>>>
>>>> Use of concurrent util is about to get changed to
>>>> backport-concurrent-util.
>>>>
>>>> Lets not forget that we changed the build system, which mostly
>>>> impacts development, but also has an impact on the configuration
>>>> files, and plugins... new CAR m2 plugin. I think it would be really
>>>> good to get an alpha out so that people can easily test and provide
>>>> feedback.
>>>>
>>>> New m2 plugin to start/stop Geronimo, soon to have new deploy goals.
>>>>
>>>> A bunch of bug fixes.
>>>>
>>>> * * *
>>>>
>>>> I think that by releasing a 1.2-alpha, that we also start down the
>>>> path of changing the perception of how quickly we release. The
>>>> alpha can also serve to help us get some experience using the m2
>>>> release plugin so that when it comes time for a non-alpha/beta
>>>> release that we have confidence in the procedure... and this will
>>>> give us time to make sure that we have the right configurations and
>>>> setup to make a release with relative ease.
>>>>
>>>> Also, more of a side effect, by making a new release, it helps
>>>> control the JIRA roadmap, right now 1.2 is filled with a bunch of
>>>> build system related fluff and other bits...
>>>>
>>>> I think that we have enough changes (or soon to change in the next
>>>> days or so) to warrant an alpha. I don't see any reason why not
>>>> to... we don't need to spend days/weeks to ensure the TCK passes,
>>>> because we don't need to run it. It should be sufficient to vote on
>>>> an alpha and then cut the release, which should be easy with the
>>>> maven release plugin, and even easier with my gpg-sign'ing mojo to
>>>> sign and upload all artifacts.
>>>>
>>>> I believe that having this alpha out will benefit our community,
>>>> showing that we are going to start releasing more often, give people
>>>> a chance to provide feedback more often an earlier.
>>>>
>>>> I certainly do not expect any production customers to use this, but
>>>> I do expect that app developers will, so they can ready their apps
>>>> for deployment on the platform. We will clearly label this as an
>>>> alpha release, and clear state that it has not been TCK certified.
>>>>
>>>> I don't see any downside to cutting a release off of trunk soonish,
>>>> in the next week or so.
>>>>
>>>> --jason
>>>>
>>>>
>>>> On Sep 6, 2006, at 9:13 AM, Kevan Miller wrote:
>>>>
>>>>>
>>>>> On Sep 5, 2006, at 4:40 PM, Dain Sundstrom wrote:
>>>>>
>>>>>> According to our STATUS file, our last feature release (1.1) was
>>>>>> on 2006-06-26 which is about 2.5 months ago. I'm not sure exactly
>>>>>> what we have in trunk right now, but I'd guess we most likely have
>>>>>> enough to do a release right now. I'm going to spend a few hours
>>>>>> today browsing the JIRAs and SVN logs and compile a list of the
>>>>>> features we have in trunk right now. Anyways, I'll let you know
>>>>>> what I find and we can figure out what we want to do.
>>>>>
>>>>> I'd be interested to hear more concretely what's in Geronimo trunk,
>>>>> OpenEJB 2.2, etc that's not in 1.1.1...
>>>>>
>>>>> --kevan
>>>>
>>>>
>>>>
>
>
>
>
Re: Release Early, Release Often
Posted by Hiram Chirino <hi...@hiramchirino.com>.
I agree. Lets stop trying to feature box so much and try to time box
more. I really don't have a problem if we get up to ver 1.14.0 in 12
months :)
If we don't release often then we can't tap our user community to help
us QA and provide feedback more often.
On 9/7/06, Jason Dillon <ja...@planet57.com> wrote:
> Something tells me that we are gonna end up with a 6mo+ release cycle
> (with additional month just to make the release)... and that if we
> are lucky.
>
> So far I'm not hearing anyone else signing the "Release Early,
> Release Often" tune.
>
> I'd stop thinking about 1.2 as JEE5 or whatever thing that is gonna
> take a bunch of time to do... and just get some incremental work done
> and push out a release.
>
> --jason
>
>
> On Sep 7, 2006, at 7:22 AM, Matt Hogstrom wrote:
>
> > I think Dain said he was scouring the primordial soup of trunk to
> > determine which level of life form would emerge. At this point if
> > its a single cell organism then a .2 release might seem
> > inappropriate. If its an intergalactic space traveler that can
> > cure cancer, solve world peace and make a good pina colada then
> > perhaps we should go to 3.0 :)
> >
> > Dain, how are we doing with the data mining? Seem like the natives
> > are getting restless :-0
> >
> > Dave Colasurdo wrote:
> >> Here is the wikipedia definition for Pre-Alpha, Alpha, Beta, etc..
> >> http://en.wikipedia.org/wiki/Alpha_release
> >> The definitions pretty much agree with my preconception of what an
> >> Alpha would contain.
> >> IMHO, trunk is not currently in an Alpha state and doesn't
> >> accurately reflect the "majority of the software requirements"
> >> that will be addressed in G1.2.
> >> It seems that trunk is currently in a pre-alpha state and I
> >> believe making an occasional unstable/nightly build available
> >> would allow users/developers to get familiar with the latest and
> >> greatest functions in trunk without giving the false impression
> >> that G1.2 is currently in Alpha state.
> >> Just my .02
> >> -Dave-
> >> Jason Dillon wrote:
> >>> I am thinking about an 1.2-alpha release, which does not need to
> >>> pass any tck, but can still be downloaded by folks that want to
> >>> test their apps on the bleeding edge (with out having to build).
> >>> While there is nothing major from a J2EE perspective in the
> >>> alpha, a lot has changed, or will change very shortly. Here is a
> >>> list with comments of new and upcoming stuff:
> >>>
> >>> ActiveMQ 4.1, is about to get committed.
> >>>
> >>> Derby is about to get upgraded.
> >>>
> >>> Log4j is about to get upgraded.
> >>>
> >>> Use of concurrent util is about to get changed to backport-
> >>> concurrent-util.
> >>>
> >>> Lets not forget that we changed the build system, which mostly
> >>> impacts development, but also has an impact on the configuration
> >>> files, and plugins... new CAR m2 plugin. I think it would be
> >>> really good to get an alpha out so that people can easily test
> >>> and provide feedback.
> >>>
> >>> New m2 plugin to start/stop Geronimo, soon to have new deploy goals.
> >>>
> >>> A bunch of bug fixes.
> >>>
> >>> * * *
> >>>
> >>> I think that by releasing a 1.2-alpha, that we also start down
> >>> the path of changing the perception of how quickly we release.
> >>> The alpha can also serve to help us get some experience using the
> >>> m2 release plugin so that when it comes time for a non-alpha/beta
> >>> release that we have confidence in the procedure... and this will
> >>> give us time to make sure that we have the right configurations
> >>> and setup to make a release with relative ease.
> >>>
> >>> Also, more of a side effect, by making a new release, it helps
> >>> control the JIRA roadmap, right now 1.2 is filled with a bunch of
> >>> build system related fluff and other bits...
> >>>
> >>> I think that we have enough changes (or soon to change in the
> >>> next days or so) to warrant an alpha. I don't see any reason why
> >>> not to... we don't need to spend days/weeks to ensure the TCK
> >>> passes, because we don't need to run it. It should be sufficient
> >>> to vote on an alpha and then cut the release, which should be
> >>> easy with the maven release plugin, and even easier with my gpg-
> >>> sign'ing mojo to sign and upload all artifacts.
> >>>
> >>> I believe that having this alpha out will benefit our community,
> >>> showing that we are going to start releasing more often, give
> >>> people a chance to provide feedback more often an earlier.
> >>>
> >>> I certainly do not expect any production customers to use this,
> >>> but I do expect that app developers will, so they can ready their
> >>> apps for deployment on the platform. We will clearly label this
> >>> as an alpha release, and clear state that it has not been TCK
> >>> certified.
> >>>
> >>> I don't see any downside to cutting a release off of trunk
> >>> soonish, in the next week or so.
> >>>
> >>> --jason
> >>>
> >>>
> >>> On Sep 6, 2006, at 9:13 AM, Kevan Miller wrote:
> >>>
> >>>>
> >>>> On Sep 5, 2006, at 4:40 PM, Dain Sundstrom wrote:
> >>>>
> >>>>> According to our STATUS file, our last feature release (1.1)
> >>>>> was on 2006-06-26 which is about 2.5 months ago. I'm not sure
> >>>>> exactly what we have in trunk right now, but I'd guess we most
> >>>>> likely have enough to do a release right now. I'm going to
> >>>>> spend a few hours today browsing the JIRAs and SVN logs and
> >>>>> compile a list of the features we have in trunk right now.
> >>>>> Anyways, I'll let you know what I find and we can figure out
> >>>>> what we want to do.
> >>>>
> >>>> I'd be interested to hear more concretely what's in Geronimo
> >>>> trunk, OpenEJB 2.2, etc that's not in 1.1.1...
> >>>>
> >>>> --kevan
> >>>
> >>>
> >>>
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Release Early, Release Often
Posted by Jason Dillon <ja...@planet57.com>.
Something tells me that we are gonna end up with a 6mo+ release cycle
(with additional month just to make the release)... and that if we
are lucky.
So far I'm not hearing anyone else signing the "Release Early,
Release Often" tune.
I'd stop thinking about 1.2 as JEE5 or whatever thing that is gonna
take a bunch of time to do... and just get some incremental work done
and push out a release.
--jason
On Sep 7, 2006, at 7:22 AM, Matt Hogstrom wrote:
> I think Dain said he was scouring the primordial soup of trunk to
> determine which level of life form would emerge. At this point if
> its a single cell organism then a .2 release might seem
> inappropriate. If its an intergalactic space traveler that can
> cure cancer, solve world peace and make a good pina colada then
> perhaps we should go to 3.0 :)
>
> Dain, how are we doing with the data mining? Seem like the natives
> are getting restless :-0
>
> Dave Colasurdo wrote:
>> Here is the wikipedia definition for Pre-Alpha, Alpha, Beta, etc..
>> http://en.wikipedia.org/wiki/Alpha_release
>> The definitions pretty much agree with my preconception of what an
>> Alpha would contain.
>> IMHO, trunk is not currently in an Alpha state and doesn't
>> accurately reflect the "majority of the software requirements"
>> that will be addressed in G1.2.
>> It seems that trunk is currently in a pre-alpha state and I
>> believe making an occasional unstable/nightly build available
>> would allow users/developers to get familiar with the latest and
>> greatest functions in trunk without giving the false impression
>> that G1.2 is currently in Alpha state.
>> Just my .02
>> -Dave-
>> Jason Dillon wrote:
>>> I am thinking about an 1.2-alpha release, which does not need to
>>> pass any tck, but can still be downloaded by folks that want to
>>> test their apps on the bleeding edge (with out having to build).
>>> While there is nothing major from a J2EE perspective in the
>>> alpha, a lot has changed, or will change very shortly. Here is a
>>> list with comments of new and upcoming stuff:
>>>
>>> ActiveMQ 4.1, is about to get committed.
>>>
>>> Derby is about to get upgraded.
>>>
>>> Log4j is about to get upgraded.
>>>
>>> Use of concurrent util is about to get changed to backport-
>>> concurrent-util.
>>>
>>> Lets not forget that we changed the build system, which mostly
>>> impacts development, but also has an impact on the configuration
>>> files, and plugins... new CAR m2 plugin. I think it would be
>>> really good to get an alpha out so that people can easily test
>>> and provide feedback.
>>>
>>> New m2 plugin to start/stop Geronimo, soon to have new deploy goals.
>>>
>>> A bunch of bug fixes.
>>>
>>> * * *
>>>
>>> I think that by releasing a 1.2-alpha, that we also start down
>>> the path of changing the perception of how quickly we release.
>>> The alpha can also serve to help us get some experience using the
>>> m2 release plugin so that when it comes time for a non-alpha/beta
>>> release that we have confidence in the procedure... and this will
>>> give us time to make sure that we have the right configurations
>>> and setup to make a release with relative ease.
>>>
>>> Also, more of a side effect, by making a new release, it helps
>>> control the JIRA roadmap, right now 1.2 is filled with a bunch of
>>> build system related fluff and other bits...
>>>
>>> I think that we have enough changes (or soon to change in the
>>> next days or so) to warrant an alpha. I don't see any reason why
>>> not to... we don't need to spend days/weeks to ensure the TCK
>>> passes, because we don't need to run it. It should be sufficient
>>> to vote on an alpha and then cut the release, which should be
>>> easy with the maven release plugin, and even easier with my gpg-
>>> sign'ing mojo to sign and upload all artifacts.
>>>
>>> I believe that having this alpha out will benefit our community,
>>> showing that we are going to start releasing more often, give
>>> people a chance to provide feedback more often an earlier.
>>>
>>> I certainly do not expect any production customers to use this,
>>> but I do expect that app developers will, so they can ready their
>>> apps for deployment on the platform. We will clearly label this
>>> as an alpha release, and clear state that it has not been TCK
>>> certified.
>>>
>>> I don't see any downside to cutting a release off of trunk
>>> soonish, in the next week or so.
>>>
>>> --jason
>>>
>>>
>>> On Sep 6, 2006, at 9:13 AM, Kevan Miller wrote:
>>>
>>>>
>>>> On Sep 5, 2006, at 4:40 PM, Dain Sundstrom wrote:
>>>>
>>>>> According to our STATUS file, our last feature release (1.1)
>>>>> was on 2006-06-26 which is about 2.5 months ago. I'm not sure
>>>>> exactly what we have in trunk right now, but I'd guess we most
>>>>> likely have enough to do a release right now. I'm going to
>>>>> spend a few hours today browsing the JIRAs and SVN logs and
>>>>> compile a list of the features we have in trunk right now.
>>>>> Anyways, I'll let you know what I find and we can figure out
>>>>> what we want to do.
>>>>
>>>> I'd be interested to hear more concretely what's in Geronimo
>>>> trunk, OpenEJB 2.2, etc that's not in 1.1.1...
>>>>
>>>> --kevan
>>>
>>>
>>>
Re: Release Early, Release Often
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I think Dain said he was scouring the primordial soup of trunk to determine which level of life form
would emerge. At this point if its a single cell organism then a .2 release might seem
inappropriate. If its an intergalactic space traveler that can cure cancer, solve world peace and
make a good pina colada then perhaps we should go to 3.0 :)
Dain, how are we doing with the data mining? Seem like the natives are getting restless :-0
Dave Colasurdo wrote:
> Here is the wikipedia definition for Pre-Alpha, Alpha, Beta, etc..
>
> http://en.wikipedia.org/wiki/Alpha_release
>
> The definitions pretty much agree with my preconception of what an Alpha
> would contain.
>
> IMHO, trunk is not currently in an Alpha state and doesn't accurately
> reflect the "majority of the software requirements" that will be
> addressed in G1.2.
>
> It seems that trunk is currently in a pre-alpha state and I believe
> making an occasional unstable/nightly build available would allow
> users/developers to get familiar with the latest and greatest functions
> in trunk without giving the false impression that G1.2 is currently in
> Alpha state.
>
> Just my .02
>
> -Dave-
>
> Jason Dillon wrote:
>> I am thinking about an 1.2-alpha release, which does not need to pass
>> any tck, but can still be downloaded by folks that want to test their
>> apps on the bleeding edge (with out having to build). While there is
>> nothing major from a J2EE perspective in the alpha, a lot has changed,
>> or will change very shortly. Here is a list with comments of new and
>> upcoming stuff:
>>
>> ActiveMQ 4.1, is about to get committed.
>>
>> Derby is about to get upgraded.
>>
>> Log4j is about to get upgraded.
>>
>> Use of concurrent util is about to get changed to
>> backport-concurrent-util.
>>
>> Lets not forget that we changed the build system, which mostly impacts
>> development, but also has an impact on the configuration files, and
>> plugins... new CAR m2 plugin. I think it would be really good to get
>> an alpha out so that people can easily test and provide feedback.
>>
>> New m2 plugin to start/stop Geronimo, soon to have new deploy goals.
>>
>> A bunch of bug fixes.
>>
>> * * *
>>
>> I think that by releasing a 1.2-alpha, that we also start down the
>> path of changing the perception of how quickly we release. The alpha
>> can also serve to help us get some experience using the m2 release
>> plugin so that when it comes time for a non-alpha/beta release that we
>> have confidence in the procedure... and this will give us time to make
>> sure that we have the right configurations and setup to make a release
>> with relative ease.
>>
>> Also, more of a side effect, by making a new release, it helps control
>> the JIRA roadmap, right now 1.2 is filled with a bunch of build system
>> related fluff and other bits...
>>
>> I think that we have enough changes (or soon to change in the next
>> days or so) to warrant an alpha. I don't see any reason why not to...
>> we don't need to spend days/weeks to ensure the TCK passes, because we
>> don't need to run it. It should be sufficient to vote on an alpha and
>> then cut the release, which should be easy with the maven release
>> plugin, and even easier with my gpg-sign'ing mojo to sign and upload
>> all artifacts.
>>
>> I believe that having this alpha out will benefit our community,
>> showing that we are going to start releasing more often, give people a
>> chance to provide feedback more often an earlier.
>>
>> I certainly do not expect any production customers to use this, but I
>> do expect that app developers will, so they can ready their apps for
>> deployment on the platform. We will clearly label this as an alpha
>> release, and clear state that it has not been TCK certified.
>>
>> I don't see any downside to cutting a release off of trunk soonish, in
>> the next week or so.
>>
>> --jason
>>
>>
>> On Sep 6, 2006, at 9:13 AM, Kevan Miller wrote:
>>
>>>
>>> On Sep 5, 2006, at 4:40 PM, Dain Sundstrom wrote:
>>>
>>>> According to our STATUS file, our last feature release (1.1) was on
>>>> 2006-06-26 which is about 2.5 months ago. I'm not sure exactly what
>>>> we have in trunk right now, but I'd guess we most likely have enough
>>>> to do a release right now. I'm going to spend a few hours today
>>>> browsing the JIRAs and SVN logs and compile a list of the features
>>>> we have in trunk right now. Anyways, I'll let you know what I find
>>>> and we can figure out what we want to do.
>>>
>>> I'd be interested to hear more concretely what's in Geronimo trunk,
>>> OpenEJB 2.2, etc that's not in 1.1.1...
>>>
>>> --kevan
>>
>>
>>
>
>
>
Re: Release Early, Release Often
Posted by Dave Colasurdo <da...@earthlink.net>.
Here is the wikipedia definition for Pre-Alpha, Alpha, Beta, etc..
http://en.wikipedia.org/wiki/Alpha_release
The definitions pretty much agree with my preconception of what an Alpha
would contain.
IMHO, trunk is not currently in an Alpha state and doesn't accurately
reflect the "majority of the software requirements" that will be
addressed in G1.2.
It seems that trunk is currently in a pre-alpha state and I believe
making an occasional unstable/nightly build available would allow
users/developers to get familiar with the latest and greatest functions
in trunk without giving the false impression that G1.2 is currently in
Alpha state.
Just my .02
-Dave-
Jason Dillon wrote:
> I am thinking about an 1.2-alpha release, which does not need to pass
> any tck, but can still be downloaded by folks that want to test their
> apps on the bleeding edge (with out having to build). While there is
> nothing major from a J2EE perspective in the alpha, a lot has changed,
> or will change very shortly. Here is a list with comments of new and
> upcoming stuff:
>
> ActiveMQ 4.1, is about to get committed.
>
> Derby is about to get upgraded.
>
> Log4j is about to get upgraded.
>
> Use of concurrent util is about to get changed to backport-concurrent-util.
>
> Lets not forget that we changed the build system, which mostly impacts
> development, but also has an impact on the configuration files, and
> plugins... new CAR m2 plugin. I think it would be really good to get an
> alpha out so that people can easily test and provide feedback.
>
> New m2 plugin to start/stop Geronimo, soon to have new deploy goals.
>
> A bunch of bug fixes.
>
> * * *
>
> I think that by releasing a 1.2-alpha, that we also start down the path
> of changing the perception of how quickly we release. The alpha can
> also serve to help us get some experience using the m2 release plugin so
> that when it comes time for a non-alpha/beta release that we have
> confidence in the procedure... and this will give us time to make sure
> that we have the right configurations and setup to make a release with
> relative ease.
>
> Also, more of a side effect, by making a new release, it helps control
> the JIRA roadmap, right now 1.2 is filled with a bunch of build system
> related fluff and other bits...
>
> I think that we have enough changes (or soon to change in the next days
> or so) to warrant an alpha. I don't see any reason why not to... we
> don't need to spend days/weeks to ensure the TCK passes, because we
> don't need to run it. It should be sufficient to vote on an alpha and
> then cut the release, which should be easy with the maven release
> plugin, and even easier with my gpg-sign'ing mojo to sign and upload all
> artifacts.
>
> I believe that having this alpha out will benefit our community, showing
> that we are going to start releasing more often, give people a chance to
> provide feedback more often an earlier.
>
> I certainly do not expect any production customers to use this, but I do
> expect that app developers will, so they can ready their apps for
> deployment on the platform. We will clearly label this as an alpha
> release, and clear state that it has not been TCK certified.
>
> I don't see any downside to cutting a release off of trunk soonish, in
> the next week or so.
>
> --jason
>
>
> On Sep 6, 2006, at 9:13 AM, Kevan Miller wrote:
>
>>
>> On Sep 5, 2006, at 4:40 PM, Dain Sundstrom wrote:
>>
>>> According to our STATUS file, our last feature release (1.1) was on
>>> 2006-06-26 which is about 2.5 months ago. I'm not sure exactly what
>>> we have in trunk right now, but I'd guess we most likely have enough
>>> to do a release right now. I'm going to spend a few hours today
>>> browsing the JIRAs and SVN logs and compile a list of the features we
>>> have in trunk right now. Anyways, I'll let you know what I find and
>>> we can figure out what we want to do.
>>
>> I'd be interested to hear more concretely what's in Geronimo trunk,
>> OpenEJB 2.2, etc that's not in 1.1.1...
>>
>> --kevan
>
>
>
Re: Release Early, Release Often
Posted by Joe Bohn <jo...@earthlink.net>.
Before we start thinking of a 1.2-alpha release we must decide what it
is that we intend to include the final 1.2 release. I don't think that
we have done this yet (which is what I was getting at with my other post
on this thread).
Once we have that content decided then we need to take a look at where
we are at with regard to delivery of that content. If we have the
major functions nearly complete then we could consider cutting an alpha
release while we continue to refine the capabilities and continue to
deliver the more minor function of the release. Anything short of that
seems to me to be just exposing a nightly build.
Joe
Jason Dillon wrote:
> I am thinking about an 1.2-alpha release, which does not need to pass
> any tck, but can still be downloaded by folks that want to test their
> apps on the bleeding edge (with out having to build). While there is
> nothing major from a J2EE perspective in the alpha, a lot has changed,
> or will change very shortly. Here is a list with comments of new and
> upcoming stuff:
>
> ActiveMQ 4.1, is about to get committed.
>
> Derby is about to get upgraded.
>
> Log4j is about to get upgraded.
>
> Use of concurrent util is about to get changed to backport-concurrent-
> util.
>
> Lets not forget that we changed the build system, which mostly impacts
> development, but also has an impact on the configuration files, and
> plugins... new CAR m2 plugin. I think it would be really good to get
> an alpha out so that people can easily test and provide feedback.
>
> New m2 plugin to start/stop Geronimo, soon to have new deploy goals.
>
> A bunch of bug fixes.
>
> * * *
>
> I think that by releasing a 1.2-alpha, that we also start down the path
> of changing the perception of how quickly we release. The alpha can
> also serve to help us get some experience using the m2 release plugin
> so that when it comes time for a non-alpha/beta release that we have
> confidence in the procedure... and this will give us time to make sure
> that we have the right configurations and setup to make a release with
> relative ease.
>
> Also, more of a side effect, by making a new release, it helps control
> the JIRA roadmap, right now 1.2 is filled with a bunch of build system
> related fluff and other bits...
>
> I think that we have enough changes (or soon to change in the next days
> or so) to warrant an alpha. I don't see any reason why not to... we
> don't need to spend days/weeks to ensure the TCK passes, because we
> don't need to run it. It should be sufficient to vote on an alpha and
> then cut the release, which should be easy with the maven release
> plugin, and even easier with my gpg-sign'ing mojo to sign and upload
> all artifacts.
>
> I believe that having this alpha out will benefit our community,
> showing that we are going to start releasing more often, give people a
> chance to provide feedback more often an earlier.
>
> I certainly do not expect any production customers to use this, but I
> do expect that app developers will, so they can ready their apps for
> deployment on the platform. We will clearly label this as an alpha
> release, and clear state that it has not been TCK certified.
>
> I don't see any downside to cutting a release off of trunk soonish, in
> the next week or so.
>
> --jason
>
>
> On Sep 6, 2006, at 9:13 AM, Kevan Miller wrote:
>
>>
>> On Sep 5, 2006, at 4:40 PM, Dain Sundstrom wrote:
>>
>>> According to our STATUS file, our last feature release (1.1) was on
>>> 2006-06-26 which is about 2.5 months ago. I'm not sure exactly what
>>> we have in trunk right now, but I'd guess we most likely have enough
>>> to do a release right now. I'm going to spend a few hours today
>>> browsing the JIRAs and SVN logs and compile a list of the features
>>> we have in trunk right now. Anyways, I'll let you know what I find
>>> and we can figure out what we want to do.
>>
>>
>> I'd be interested to hear more concretely what's in Geronimo trunk,
>> OpenEJB 2.2, etc that's not in 1.1.1...
>>
>> --kevan
>
>
>
>
Re: Release Early, Release Often
Posted by Matt Hogstrom <ma...@hogstrom.org>.
From an ASF perspective is there a difference between releasing an Alpha versus a full release ?
Avoiding TCK will help significantly.
Jason Dillon wrote:
> We will get to that soon enough, though I don't believe that would be a
> replacement for alpha/beta releases.
>
> --jason
>
>
> On Sep 6, 2006, at 3:55 PM, Jeff Genender wrote:
>
>> We kind of discussed this before...
>>
>> But why not have the automated nightly build from trunk?
>>
>> Jason Dillon wrote:
>>> I am thinking about an 1.2-alpha release, which does not need to pass
>>> any tck, but can still be downloaded by folks that want to test their
>>> apps on the bleeding edge (with out having to build). While there is
>>> nothing major from a J2EE perspective in the alpha, a lot has changed,
>>> or will change very shortly. Here is a list with comments of new and
>>> upcoming stuff:
>>>
>>> ActiveMQ 4.1, is about to get committed.
>>>
>>> Derby is about to get upgraded.
>>>
>>> Log4j is about to get upgraded.
>>>
>>> Use of concurrent util is about to get changed to
>>> backport-concurrent-util.
>>>
>>> Lets not forget that we changed the build system, which mostly impacts
>>> development, but also has an impact on the configuration files, and
>>> plugins... new CAR m2 plugin. I think it would be really good to get an
>>> alpha out so that people can easily test and provide feedback.
>>>
>>> New m2 plugin to start/stop Geronimo, soon to have new deploy goals.
>>>
>>> A bunch of bug fixes.
>>>
>>> * * *
>>>
>>> I think that by releasing a 1.2-alpha, that we also start down the path
>>> of changing the perception of how quickly we release. The alpha can
>>> also serve to help us get some experience using the m2 release plugin so
>>> that when it comes time for a non-alpha/beta release that we have
>>> confidence in the procedure... and this will give us time to make sure
>>> that we have the right configurations and setup to make a release with
>>> relative ease.
>>>
>>> Also, more of a side effect, by making a new release, it helps control
>>> the JIRA roadmap, right now 1.2 is filled with a bunch of build system
>>> related fluff and other bits...
>>>
>>> I think that we have enough changes (or soon to change in the next days
>>> or so) to warrant an alpha. I don't see any reason why not to... we
>>> don't need to spend days/weeks to ensure the TCK passes, because we
>>> don't need to run it. It should be sufficient to vote on an alpha and
>>> then cut the release, which should be easy with the maven release
>>> plugin, and even easier with my gpg-sign'ing mojo to sign and upload all
>>> artifacts.
>>>
>>> I believe that having this alpha out will benefit our community, showing
>>> that we are going to start releasing more often, give people a chance to
>>> provide feedback more often an earlier.
>>>
>>> I certainly do not expect any production customers to use this, but I do
>>> expect that app developers will, so they can ready their apps for
>>> deployment on the platform. We will clearly label this as an alpha
>>> release, and clear state that it has not been TCK certified.
>>>
>>> I don't see any downside to cutting a release off of trunk soonish, in
>>> the next week or so.
>>>
>>> --jason
>>>
>>>
>>> On Sep 6, 2006, at 9:13 AM, Kevan Miller wrote:
>>>
>>>>
>>>> On Sep 5, 2006, at 4:40 PM, Dain Sundstrom wrote:
>>>>
>>>>> According to our STATUS file, our last feature release (1.1) was on
>>>>> 2006-06-26 which is about 2.5 months ago. I'm not sure exactly what
>>>>> we have in trunk right now, but I'd guess we most likely have enough
>>>>> to do a release right now. I'm going to spend a few hours today
>>>>> browsing the JIRAs and SVN logs and compile a list of the features we
>>>>> have in trunk right now. Anyways, I'll let you know what I find and
>>>>> we can figure out what we want to do.
>>>>
>>>> I'd be interested to hear more concretely what's in Geronimo trunk,
>>>> OpenEJB 2.2, etc that's not in 1.1.1...
>>>>
>>>> --kevan
>
>
>
>
Re: Release Early, Release Often
Posted by Jason Dillon <ja...@planet57.com>.
We will get to that soon enough, though I don't believe that would be
a replacement for alpha/beta releases.
--jason
On Sep 6, 2006, at 3:55 PM, Jeff Genender wrote:
> We kind of discussed this before...
>
> But why not have the automated nightly build from trunk?
>
> Jason Dillon wrote:
>> I am thinking about an 1.2-alpha release, which does not need to pass
>> any tck, but can still be downloaded by folks that want to test their
>> apps on the bleeding edge (with out having to build). While there is
>> nothing major from a J2EE perspective in the alpha, a lot has
>> changed,
>> or will change very shortly. Here is a list with comments of new and
>> upcoming stuff:
>>
>> ActiveMQ 4.1, is about to get committed.
>>
>> Derby is about to get upgraded.
>>
>> Log4j is about to get upgraded.
>>
>> Use of concurrent util is about to get changed to backport-
>> concurrent-util.
>>
>> Lets not forget that we changed the build system, which mostly
>> impacts
>> development, but also has an impact on the configuration files, and
>> plugins... new CAR m2 plugin. I think it would be really good to
>> get an
>> alpha out so that people can easily test and provide feedback.
>>
>> New m2 plugin to start/stop Geronimo, soon to have new deploy goals.
>>
>> A bunch of bug fixes.
>>
>> * * *
>>
>> I think that by releasing a 1.2-alpha, that we also start down the
>> path
>> of changing the perception of how quickly we release. The alpha can
>> also serve to help us get some experience using the m2 release
>> plugin so
>> that when it comes time for a non-alpha/beta release that we have
>> confidence in the procedure... and this will give us time to make
>> sure
>> that we have the right configurations and setup to make a release
>> with
>> relative ease.
>>
>> Also, more of a side effect, by making a new release, it helps
>> control
>> the JIRA roadmap, right now 1.2 is filled with a bunch of build
>> system
>> related fluff and other bits...
>>
>> I think that we have enough changes (or soon to change in the next
>> days
>> or so) to warrant an alpha. I don't see any reason why not to... we
>> don't need to spend days/weeks to ensure the TCK passes, because we
>> don't need to run it. It should be sufficient to vote on an alpha
>> and
>> then cut the release, which should be easy with the maven release
>> plugin, and even easier with my gpg-sign'ing mojo to sign and
>> upload all
>> artifacts.
>>
>> I believe that having this alpha out will benefit our community,
>> showing
>> that we are going to start releasing more often, give people a
>> chance to
>> provide feedback more often an earlier.
>>
>> I certainly do not expect any production customers to use this,
>> but I do
>> expect that app developers will, so they can ready their apps for
>> deployment on the platform. We will clearly label this as an alpha
>> release, and clear state that it has not been TCK certified.
>>
>> I don't see any downside to cutting a release off of trunk
>> soonish, in
>> the next week or so.
>>
>> --jason
>>
>>
>> On Sep 6, 2006, at 9:13 AM, Kevan Miller wrote:
>>
>>>
>>> On Sep 5, 2006, at 4:40 PM, Dain Sundstrom wrote:
>>>
>>>> According to our STATUS file, our last feature release (1.1) was on
>>>> 2006-06-26 which is about 2.5 months ago. I'm not sure exactly
>>>> what
>>>> we have in trunk right now, but I'd guess we most likely have
>>>> enough
>>>> to do a release right now. I'm going to spend a few hours today
>>>> browsing the JIRAs and SVN logs and compile a list of the
>>>> features we
>>>> have in trunk right now. Anyways, I'll let you know what I find and
>>>> we can figure out what we want to do.
>>>
>>> I'd be interested to hear more concretely what's in Geronimo trunk,
>>> OpenEJB 2.2, etc that's not in 1.1.1...
>>>
>>> --kevan
Re: Release Early, Release Often
Posted by Sergey Elin <el...@gmail.com>.
I think it is good idea! ;)
2006/9/7, Jeff Genender <jg...@apache.org>:
>
> We kind of discussed this before...
>
> But why not have the automated nightly build from trunk?
>
> Jason Dillon wrote:
> > I am thinking about an 1.2-alpha release, which does not need to pass
> > any tck, but can still be downloaded by folks that want to test their
> > apps on the bleeding edge (with out having to build). While there is
> > nothing major from a J2EE perspective in the alpha, a lot has changed,
> > or will change very shortly. Here is a list with comments of new and
> > upcoming stuff:
> >
> > ActiveMQ 4.1, is about to get committed.
> >
> > Derby is about to get upgraded.
> >
> > Log4j is about to get upgraded.
> >
> > Use of concurrent util is about to get changed to
> backport-concurrent-util.
> >
> > Lets not forget that we changed the build system, which mostly impacts
> > development, but also has an impact on the configuration files, and
> > plugins... new CAR m2 plugin. I think it would be really good to get an
> > alpha out so that people can easily test and provide feedback.
> >
> > New m2 plugin to start/stop Geronimo, soon to have new deploy goals.
> >
> > A bunch of bug fixes.
> >
> > * * *
> >
> > I think that by releasing a 1.2-alpha, that we also start down the path
> > of changing the perception of how quickly we release. The alpha can
> > also serve to help us get some experience using the m2 release plugin so
> > that when it comes time for a non-alpha/beta release that we have
> > confidence in the procedure... and this will give us time to make sure
> > that we have the right configurations and setup to make a release with
> > relative ease.
> >
> > Also, more of a side effect, by making a new release, it helps control
> > the JIRA roadmap, right now 1.2 is filled with a bunch of build system
> > related fluff and other bits...
> >
> > I think that we have enough changes (or soon to change in the next days
> > or so) to warrant an alpha. I don't see any reason why not to... we
> > don't need to spend days/weeks to ensure the TCK passes, because we
> > don't need to run it. It should be sufficient to vote on an alpha and
> > then cut the release, which should be easy with the maven release
> > plugin, and even easier with my gpg-sign'ing mojo to sign and upload all
> > artifacts.
> >
> > I believe that having this alpha out will benefit our community, showing
> > that we are going to start releasing more often, give people a chance to
> > provide feedback more often an earlier.
> >
> > I certainly do not expect any production customers to use this, but I do
> > expect that app developers will, so they can ready their apps for
> > deployment on the platform. We will clearly label this as an alpha
> > release, and clear state that it has not been TCK certified.
> >
> > I don't see any downside to cutting a release off of trunk soonish, in
> > the next week or so.
> >
> > --jason
> >
> >
> > On Sep 6, 2006, at 9:13 AM, Kevan Miller wrote:
> >
> >>
> >> On Sep 5, 2006, at 4:40 PM, Dain Sundstrom wrote:
> >>
> >>> According to our STATUS file, our last feature release (1.1) was on
> >>> 2006-06-26 which is about 2.5 months ago. I'm not sure exactly what
> >>> we have in trunk right now, but I'd guess we most likely have enough
> >>> to do a release right now. I'm going to spend a few hours today
> >>> browsing the JIRAs and SVN logs and compile a list of the features we
> >>> have in trunk right now. Anyways, I'll let you know what I find and
> >>> we can figure out what we want to do.
> >>
> >> I'd be interested to hear more concretely what's in Geronimo trunk,
> >> OpenEJB 2.2, etc that's not in 1.1.1...
> >>
> >> --kevan
>
Re: Release Early, Release Often
Posted by Jeff Genender <jg...@apache.org>.
We kind of discussed this before...
But why not have the automated nightly build from trunk?
Jason Dillon wrote:
> I am thinking about an 1.2-alpha release, which does not need to pass
> any tck, but can still be downloaded by folks that want to test their
> apps on the bleeding edge (with out having to build). While there is
> nothing major from a J2EE perspective in the alpha, a lot has changed,
> or will change very shortly. Here is a list with comments of new and
> upcoming stuff:
>
> ActiveMQ 4.1, is about to get committed.
>
> Derby is about to get upgraded.
>
> Log4j is about to get upgraded.
>
> Use of concurrent util is about to get changed to backport-concurrent-util.
>
> Lets not forget that we changed the build system, which mostly impacts
> development, but also has an impact on the configuration files, and
> plugins... new CAR m2 plugin. I think it would be really good to get an
> alpha out so that people can easily test and provide feedback.
>
> New m2 plugin to start/stop Geronimo, soon to have new deploy goals.
>
> A bunch of bug fixes.
>
> * * *
>
> I think that by releasing a 1.2-alpha, that we also start down the path
> of changing the perception of how quickly we release. The alpha can
> also serve to help us get some experience using the m2 release plugin so
> that when it comes time for a non-alpha/beta release that we have
> confidence in the procedure... and this will give us time to make sure
> that we have the right configurations and setup to make a release with
> relative ease.
>
> Also, more of a side effect, by making a new release, it helps control
> the JIRA roadmap, right now 1.2 is filled with a bunch of build system
> related fluff and other bits...
>
> I think that we have enough changes (or soon to change in the next days
> or so) to warrant an alpha. I don't see any reason why not to... we
> don't need to spend days/weeks to ensure the TCK passes, because we
> don't need to run it. It should be sufficient to vote on an alpha and
> then cut the release, which should be easy with the maven release
> plugin, and even easier with my gpg-sign'ing mojo to sign and upload all
> artifacts.
>
> I believe that having this alpha out will benefit our community, showing
> that we are going to start releasing more often, give people a chance to
> provide feedback more often an earlier.
>
> I certainly do not expect any production customers to use this, but I do
> expect that app developers will, so they can ready their apps for
> deployment on the platform. We will clearly label this as an alpha
> release, and clear state that it has not been TCK certified.
>
> I don't see any downside to cutting a release off of trunk soonish, in
> the next week or so.
>
> --jason
>
>
> On Sep 6, 2006, at 9:13 AM, Kevan Miller wrote:
>
>>
>> On Sep 5, 2006, at 4:40 PM, Dain Sundstrom wrote:
>>
>>> According to our STATUS file, our last feature release (1.1) was on
>>> 2006-06-26 which is about 2.5 months ago. I'm not sure exactly what
>>> we have in trunk right now, but I'd guess we most likely have enough
>>> to do a release right now. I'm going to spend a few hours today
>>> browsing the JIRAs and SVN logs and compile a list of the features we
>>> have in trunk right now. Anyways, I'll let you know what I find and
>>> we can figure out what we want to do.
>>
>> I'd be interested to hear more concretely what's in Geronimo trunk,
>> OpenEJB 2.2, etc that's not in 1.1.1...
>>
>> --kevan
Re: Release Early, Release Often
Posted by Jason Dillon <ja...@planet57.com>.
I am thinking about an 1.2-alpha release, which does not need to pass
any tck, but can still be downloaded by folks that want to test their
apps on the bleeding edge (with out having to build). While there is
nothing major from a J2EE perspective in the alpha, a lot has
changed, or will change very shortly. Here is a list with comments
of new and upcoming stuff:
ActiveMQ 4.1, is about to get committed.
Derby is about to get upgraded.
Log4j is about to get upgraded.
Use of concurrent util is about to get changed to backport-concurrent-
util.
Lets not forget that we changed the build system, which mostly
impacts development, but also has an impact on the configuration
files, and plugins... new CAR m2 plugin. I think it would be really
good to get an alpha out so that people can easily test and provide
feedback.
New m2 plugin to start/stop Geronimo, soon to have new deploy goals.
A bunch of bug fixes.
* * *
I think that by releasing a 1.2-alpha, that we also start down the
path of changing the perception of how quickly we release. The alpha
can also serve to help us get some experience using the m2 release
plugin so that when it comes time for a non-alpha/beta release that
we have confidence in the procedure... and this will give us time to
make sure that we have the right configurations and setup to make a
release with relative ease.
Also, more of a side effect, by making a new release, it helps
control the JIRA roadmap, right now 1.2 is filled with a bunch of
build system related fluff and other bits...
I think that we have enough changes (or soon to change in the next
days or so) to warrant an alpha. I don't see any reason why not
to... we don't need to spend days/weeks to ensure the TCK passes,
because we don't need to run it. It should be sufficient to vote on
an alpha and then cut the release, which should be easy with the
maven release plugin, and even easier with my gpg-sign'ing mojo to
sign and upload all artifacts.
I believe that having this alpha out will benefit our community,
showing that we are going to start releasing more often, give people
a chance to provide feedback more often an earlier.
I certainly do not expect any production customers to use this, but I
do expect that app developers will, so they can ready their apps for
deployment on the platform. We will clearly label this as an alpha
release, and clear state that it has not been TCK certified.
I don't see any downside to cutting a release off of trunk soonish,
in the next week or so.
--jason
On Sep 6, 2006, at 9:13 AM, Kevan Miller wrote:
>
> On Sep 5, 2006, at 4:40 PM, Dain Sundstrom wrote:
>
>> According to our STATUS file, our last feature release (1.1) was
>> on 2006-06-26 which is about 2.5 months ago. I'm not sure exactly
>> what we have in trunk right now, but I'd guess we most likely have
>> enough to do a release right now. I'm going to spend a few hours
>> today browsing the JIRAs and SVN logs and compile a list of the
>> features we have in trunk right now. Anyways, I'll let you know
>> what I find and we can figure out what we want to do.
>
> I'd be interested to hear more concretely what's in Geronimo trunk,
> OpenEJB 2.2, etc that's not in 1.1.1...
>
> --kevan
Re: Release Early, Release Often
Posted by Kevan Miller <ke...@gmail.com>.
On Sep 5, 2006, at 4:40 PM, Dain Sundstrom wrote:
> According to our STATUS file, our last feature release (1.1) was on
> 2006-06-26 which is about 2.5 months ago. I'm not sure exactly
> what we have in trunk right now, but I'd guess we most likely have
> enough to do a release right now. I'm going to spend a few hours
> today browsing the JIRAs and SVN logs and compile a list of the
> features we have in trunk right now. Anyways, I'll let you know
> what I find and we can figure out what we want to do.
I'd be interested to hear more concretely what's in Geronimo trunk,
OpenEJB 2.2, etc that's not in 1.1.1...
--kevan
Re: Release Early, Release Often
Posted by Hiram Chirino <hi...@hiramchirino.com>.
ActiveMQ 4.1 is going in now that we got the 3 pmc vote.. woot! thanks
for all who checked the patch out.
On 9/6/06, Joe Bohn <jo...@earthlink.net> wrote:
> I'd also be interested in seeing what is actually in trunk already.
> However, I'd be surprised if we really have a enough functionality for
> this to be considered a feature release.
>
> I've heard several people talk about functions that they would like to
> see included in 1.2: Yoko, Java 5, JPA integration, clustering,
> GShell, pluggable JACC (may be already there), CMP for JPA, Usability
> improvements (esp. web console), performance improvements, etc... What
> of these capabilities do we as a community feel are critical to be
> competitive?
>
> There are at least 2 items that I'd like to get into 1.2 before we
> release it:
>
> 1) A new repository implementation and/or other improvements in the
> file system to provide some relief on the Windows pathlength issue as
> well as make it easier to locate deployed applications.
>
> 2) A framework assembly (basically little-G without a container) to be
> used as a foundation for building template based servers from the
> framework + plugins providing a "roll your own" server capability to our
> users. This is just a start at this notion which will also require a
> number of other functions (either in 1.2 or, more likely, in a
> subsequent release).
>
> Joe
>
>
> Dain Sundstrom wrote:
> > According to our STATUS file, our last feature release (1.1) was on
> > 2006-06-26 which is about 2.5 months ago. I'm not sure exactly what we
> > have in trunk right now, but I'd guess we most likely have enough to do
> > a release right now. I'm going to spend a few hours today browsing
> > the JIRAs and SVN logs and compile a list of the features we have in
> > trunk right now. Anyways, I'll let you know what I find and we can
> > figure out what we want to do.
> >
> > Thanks,
> >
> > -dain
> >
> >
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Release Early, Release Often
Posted by Joe Bohn <jo...@earthlink.net>.
I'd also be interested in seeing what is actually in trunk already.
However, I'd be surprised if we really have a enough functionality for
this to be considered a feature release.
I've heard several people talk about functions that they would like to
see included in 1.2: Yoko, Java 5, JPA integration, clustering,
GShell, pluggable JACC (may be already there), CMP for JPA, Usability
improvements (esp. web console), performance improvements, etc... What
of these capabilities do we as a community feel are critical to be
competitive?
There are at least 2 items that I'd like to get into 1.2 before we
release it:
1) A new repository implementation and/or other improvements in the
file system to provide some relief on the Windows pathlength issue as
well as make it easier to locate deployed applications.
2) A framework assembly (basically little-G without a container) to be
used as a foundation for building template based servers from the
framework + plugins providing a "roll your own" server capability to our
users. This is just a start at this notion which will also require a
number of other functions (either in 1.2 or, more likely, in a
subsequent release).
Joe
Dain Sundstrom wrote:
> According to our STATUS file, our last feature release (1.1) was on
> 2006-06-26 which is about 2.5 months ago. I'm not sure exactly what we
> have in trunk right now, but I'd guess we most likely have enough to do
> a release right now. I'm going to spend a few hours today browsing
> the JIRAs and SVN logs and compile a list of the features we have in
> trunk right now. Anyways, I'll let you know what I find and we can
> figure out what we want to do.
>
> Thanks,
>
> -dain
>
>
Re: Release Early, Release Often
Posted by David Jencks <da...@yahoo.com>.
I'd like to get the cm jpa stuff I'm working on in, together with the
reorganization of naming-builder I'm working on. With luck the
latter will be ready soon, the former I'm waiting for votes.
There are a bunch of jiras/bug fixes that still need to be forward
ported to trunk, and the stuff in all_changes.log is still not
addressed to a considerable extent.
Other than these, I'm fine with releasing something soon.
thanks
david jencks
On Sep 5, 2006, at 4:40 PM, Dain Sundstrom wrote:
> According to our STATUS file, our last feature release (1.1) was on
> 2006-06-26 which is about 2.5 months ago. I'm not sure exactly
> what we have in trunk right now, but I'd guess we most likely have
> enough to do a release right now. I'm going to spend a few hours
> today browsing the JIRAs and SVN logs and compile a list of the
> features we have in trunk right now. Anyways, I'll let you know
> what I find and we can figure out what we want to do.
>
> Thanks,
>
> -dain
Re: Release Early, Release Often
Posted by Dain Sundstrom <da...@iq80.com>.
For those of you interested in the unfiltered list of completed
JIRAs, here they are :)
-dain
New Features (8):
* [GERONIMO-1133] UUID primary key generator
* [GERONIMO-1192] Installer should create a config.xml for the
target install
* [GERONIMO-1259] reduce the size of the combined deployment plan:
package deployment plans in a jar and pass this jar to the deployer
* [GERONIMO-1573] Spring integration -- wrap our components in
spring interfaces
* [GERONIMO-1593] Add SMTP Authentication and STARTTLS support.
* [GERONIMO-2071] Move Geronimo build to M2 (new 1.2 trunk)
* [GERONIMO-2132] Move activemq gbean integration modules from
ActiveMQ to Geronimo
* [GERONIMO-2148] Add javamail 1.4 to geronimo specs.
Improvements (41):
* [GERONIMO-790] JettyModuleBuilder should use references to
templates, not their names
* [GERONIMO-1075] Configuration classloaders should support an
inverse classloading delegation model.
* [GERONIMO-1163] improve jmx debug console
* [GERONIMO-1194] Installer should only install packs(features)
selected at install time
* [GERONIMO-1278] Upgrade to XML Beans 2.1.0 from 2.0.0
* [GERONIMO-1317] Rename the "new" goals to more meaningful names
with additional build properties
* [GERONIMO-1335] Create issues for making the plugins run in more
ways
* [GERONIMO-1401] Updates to BUILDING.txt about the last changes
to the build process
* [GERONIMO-1429] Post Geronimo Schemas online (e.g. http://
java.sun.com/xml/ns/j2ee/)
* [GERONIMO-1434] Allow GBeans to be bound into a component's
java:comp/env namespace
* [GERONIMO-1479] Add the maxPostSize and maxSavePostSize
attributes to the Tomcat ConnectorGBean
* [GERONIMO-1527] InternetAddress does not properly implement
address parsing.
* [GERONIMO-1554] Installer - Move advanced features to non-
default installer path (simplify default installation)
* [GERONIMO-1563] [RTC] Make the JACC implementation pluggable
* [GERONIMO-1571] Just a suggestion to state in the source
distributin's BUILDING.txt file that compilation requires a JDK
compatible with version 1.4, and that 1.5 will not work.
* [GERONIMO-1605] Display PID of started process when using
geronimo.sh start or startup.sh
* [GERONIMO-1606] Display message indicating Geronimo is being
started in another window when started with geronimo.bat start or
startup.bat
* [GERONIMO-1607] Allow user to specify arguments to be used on
the Windows START command issued by geronimo.bat
* [GERONIMO-1608] Improve Geronimo script documentation
* [GERONIMO-1613] Eliminate unncessary dependencies to reduce
assemnbly footprint size
* [GERONIMO-1647] Enabling access to session id on Tomcat
* [GERONIMO-1648] Eliminate unnecessary config parent (import)
dependencies
* [GERONIMO-1651] Complete implementation of javamail MimeMessage
and MimeUtil classes.
* [GERONIMO-1664] Export / Import configurations capability
* [GERONIMO-1705] Use AJAX to provide for a progress bar when
downloading a JDBC jar
* [GERONIMO-1772] Application class loader should not see server
classes
* [GERONIMO-1796] Improve SMTP transport debug trace output.
* [GERONIMO-1798] Bring NNTPStore and NNTPTransport to same level
of debugging tracing added to SMTP.
* [GERONIMO-1881] Remove obsolete interop module
* [GERONIMO-1960] Reject invalid GBean references at deployment time
* [GERONIMO-2092] Modules migration to M2
* [GERONIMO-2135] Improve the ActiveMQ GBeans
* [GERONIMO-2147] Remove javamail-transport from Geronimo build
and replace with javamail-provider dependency.
* [GERONIMO-2152] Update for new OpenEJB 2.2
* [GERONIMO-2216] Use JLine API to get password interactivly when
using shutdown
* [GERONIMO-2224] Add a geronimo specific system property for
controlling dom, sax, and transformer creation
* [GERONIMO-2277] Remove TransactionContextManager
* [GERONIMO-2299] Unpack assemblies for easier development/testing
* [GERONIMO-2300] Use jar or assembly plugin to generate classpath/
manifest bits for stuff in bin/*
* [GERONIMO-2345] Windows Version of bootstrap
* [GERONIMO-2374] use junit decorators with selenium
Bug Fixes (180):
* [GERONIMO-526] Default domain not added to object names
* [GERONIMO-592] Startup failure in Turkish language settings
* [GERONIMO-973] Add security to /console-standard
* [GERONIMO-1012] Tomcat integration does not set a subject in an
unsecured web module in a secured ejb application
* [GERONIMO-1097] (Patch) Keystore Portlet should point to the
default keystore file instead of ssl-keystore-1
* [GERONIMO-1165] Changing System DB pool size to 65 causes
ActiveMQ to fail to get a connection
* [GERONIMO-1176] Bad "resource" reference is not caught at
deployment time
* [GERONIMO-1182] Connector portlet delete challenge
* [GERONIMO-1183] Console/Tomcat: Add/Edit Jetty HTTPS Connector
page does not provide "key password" field
* [GERONIMO-1196] Keystore portlet: Viewing trusted certificate
results in an error
* [GERONIMO-1287] IzPack Installer does not set line endings to
CRLF on windows and LF on non-Windows platforms
* [GERONIMO-1307] JMX connector doesn't shut down cleanly
* [GERONIMO-1313] openejb builder listener attribute has bad
object name
* [GERONIMO-1316] Create JMS destination pretty darn broken
* [GERONIMO-1331] QName class escaped from startup classpath
* [GERONIMO-1334] 142 config-store directories are created during
a build
* [GERONIMO-1336] Setting the Max PoolSize on a DataBase pool with
invalid information does not yield an error message and silently fails
* [GERONIMO-1339] db pool size & connection attributes are not
saved in config.xml
* [GERONIMO-1340] Assemblies include all car files in the repository
* [GERONIMO-1344] Get java usage help when a trailing slash '/' is
in GERONIMO_HOME environment variable when running geronimo.bat
* [GERONIMO-1345] Connection pool resizing does not calculate what
to do correctly
* [GERONIMO-1348] Packaging plugin does not set extension directories
* [GERONIMO-1352] RMI port number is not specified in URL for
JMXConnector in server config.xml files
* [GERONIMO-1370] velocity.log is created in current directory on
server startup
* [GERONIMO-1379] Login Error page does not include updates to
remove table and include About link
* [GERONIMO-1387] Geronimo Console Applications portlets fail
after starting app client.
* [GERONIMO-1395] text files (except *.bat files) have LF endings
in ZIP file
* [GERONIMO-1406] BUILDING.txt needs update to reflect the
removing of assembly directory
* [GERONIMO-1409] A Filter is initialized with a wrong TCCL.
* [GERONIMO-1411] servlet 2.3 context-param elements are not
converted properly to servlet 2.4 schema
* [GERONIMO-1416] [daytrader] Broken links on benchmarking page
* [GERONIMO-1419] javax.mail.internet.InternetHeaders has some non
implemented features
* [GERONIMO-1425] access to unprotected web resource after login
does not use correct Subject
* [GERONIMO-1433] Security vulnerability of WEB-INF contents on
windows platforms
* [GERONIMO-1435] resource-env-ref mapping by admin-object-link
broken
* [GERONIMO-1436] [daytrader] Build instructions in applications
\daytrader\README file out of date
* [GERONIMO-1437] INFO [Http11Protocol] messages (from tomcat)
written to stdout during startup of Geronimo
* [GERONIMO-1438] INFO [StandardContext] logged (from Tomcat)
during shutdown of Geronimo
* [GERONIMO-1440] JAASJettyRealm not shared enough
* [GERONIMO-1441] "Build path contains duplicate entry" errors for
some geronimo projects in eclipse
* [GERONIMO-1443] The hot deployer should accept plan-only
deployments just like the online deployer
* [GERONIMO-1446] Tomcat server assembly does not include geronimo
javamail car
* [GERONIMO-1447] MagicGBall sample does not work in AG 1.0
* [GERONIMO-1448] debug-tool does not work on Tomcat
* [GERONIMO-1450] Console usage plans use old namspace & parentId
* [GERONIMO-1452] Config.xml refers to the wrong JMX remote
service gbean (Fix included)
* [GERONIMO-1455] Start of CAR does not load and start its GBeans
* [GERONIMO-1456] geronimo-1.0-src.zip has a meta-inf folder in
the root directory
* [GERONIMO-1457] Change trunk version to 1.1-SNAPSHOT
* [GERONIMO-1463] Tomcat doesn't always get the right servlet name
when evaluating isUserInRole
* [GERONIMO-1465] FixCRLF processing in assembly plugin sometimes
fails under windows trying to rename a temp file
* [GERONIMO-1467] DB pool portlet error when web session saved
* [GERONIMO-1468] FileSystemRepository#listUris() produces wrong
URI array when the repository contains a malformed entry
* [GERONIMO-1473] ApplicationPolicyConfigurationManager doesn't
clear permissions on startup
* [GERONIMO-1474] Cross site scripting vulnerabilites
* [GERONIMO-1477] JMX debug tool should not be loaded in the
supplied config.xml
* [GERONIMO-1480] Cross context include does not set jacc
contextID for 2nd web app. (Tomcat only)
* [GERONIMO-1489] Minor fixes/updates to jUDDI webapp and Tomcat
config
* [GERONIMO-1490] setjavaenv.bat is not called by deploy.bat
* [GERONIMO-1497] DatabasePoolPortlet Unable to save connection pool
* [GERONIMO-1503] keystore generated by KeyStore portlet could not
be used to add either Jetty or Tomcat HTTPS Listeners
* [GERONIMO-1505] Installer should default Tomcat on at runtime if
Jetty pack is not selected
* [GERONIMO-1513] The directory "geronimo-1.0\lib\extension" does
not match the "Extension-Dirs: lib/ext" value in server.jar's
manifest.mf file
* [GERONIMO-1517] Installer - Install Derby with base J2EE Features
* [GERONIMO-1523] Openejb corba class is included (serialized) in
all enc contexts
* [GERONIMO-1525] Error in DB Pool Portlet
* [GERONIMO-1528] javax.mail.BodyPart does not implement setParent
() method
* [GERONIMO-1530] javax.mail.Service does not properly implement
the protocol between javamail infrastructure and transport handlers.
* [GERONIMO-1535] Error in security realm portlet
* [GERONIMO-1536] Installer - j2ee-installer assembly project.xml fix
* [GERONIMO-1537] Installer - IzPack assembly does not qualify
plugin version for code copied to installer assembly for use at
install time
* [GERONIMO-1540] Fix security vulnerability in jsp-examples
* [GERONIMO-1541] Unable to deploy applications in new Minimal and
WEB-JMS assemblies
* [GERONIMO-1558] InternetHeaders not handling setHeader(String
name, Address[] addresses) properly.
* [GERONIMO-1561] Misspelling in Kernel Exception Message
* [GERONIMO-1566] Binary distributions (both zip and tgz) contain
a META-INF/manifest.mf file under the geronimo-1.0 directory.
* [GERONIMO-1569] improve packaging plugin control of logging.
* [GERONIMO-1570] jetty is setting hosts instead of virtual hosts
* [GERONIMO-1578] Including wadi and its dependencies in the jetty
configuration/classpath breaks numerous bits of geronimo
* [GERONIMO-1695] CORBA for EJB with Local interface only causes NPE
* [GERONIMO-1596] Repeated interface in JMS connection factory
plan causes deployment failure
* [GERONIMO-1599] HOWLLog throws NPE because XidFactory is missing
* [GERONIMO-1603] shutdown.bat does not set ERRORLEVEL and does
not honour GERONIMO_BATCH_ECHO and GERONIMO_BATCH_PAUSE environment
variables
* [GERONIMO-1604] Output from deploy.sh/bat is inconsistent with
other scripts - does not output info on environment variable settings
(e.g. JAVA_HOME)
* [GERONIMO-1609] Fix typo in error message in geronimo.bat -
"cannot find ...setclasspath.bat" should read "cannot
find ...setjavaenv.bat"
* [GERONIMO-1610] deploy.bat does not honour GERONIMO_BATCH_ECHO
and GERONIMO_BATCH_PAUSE environment variables
* [GERONIMO-1612] Remove -
Djava.endorsed.dirs="$JAVA_ENDORSED_DIRS" from commands in geronimo.sh
* [GERONIMO-1615] CSS GSSUP dynamic auth sends domain name as
username
* [GERONIMO-1616] CSS GSSUP token encoding sets username to
username@domain but decoding does not reverse that
* [GERONIMO-1634] NoClassDefFoundError from Derby Log Viewer
* [GERONIMO-1643] NullTransport class needs to implement
protocolConnect
* [GERONIMO-1649] Invalid deployment descriptor error when
deploying an EJB 2.0 MDB
* [GERONIMO-1669] javamail Transport.send() is not issuing connect
() on the transport before sending the message.
* [GERONIMO-1671] InternetAddress.getLocalAddress() does not
properly implement the local address resolution path.
* [GERONIMO-1676] Tomcat assembly get FileNotFoundException for
geronimo.log during server initalization
* [GERONIMO-1696] JPDA run command not listed in usage help for
geronimo.sh and geronimo.bat
* [GERONIMO-1699] jdom classes not available for information portlet
* [GERONIMO-1743] Deploy.bat doesn't accept any arguments and
hence doesn't work.
* [GERONIMO-1744] "dt_shmem" default in geronimo.bat for
JPDA_TRANSPORT environment variable not compatible with Eclipse debugger
* [GERONIMO-1745] The JPDA_OPTS environment variable is not
honoured by geronimo.bat and is inconsistent with geronimo.sh
* [GERONIMO-1765] POP3 and NNTP messages should throw an exception
if headers are modified.
* [GERONIMO-1788] Allow for disabling of cookies in web application
* [GERONIMO-1793] MimeBodyPart setDescription()/getDescription()
is not properly encoding header description data.
* [GERONIMO-1794] javamail Service class is not setting debug flag.
* [GERONIMO-1797] Mail attachments are not getting recognized as
MIME parts
* [GERONIMO-1819] Port SQL realm fix from 1.1 to HEAD
* [GERONIMO-1822] Connector builder doesn't check consistency of
transaction settings
* [GERONIMO-1887] Remove unneeded jars from console WEB-INF/lib
directories
* [GERONIMO-1965] NNTPSTransportGBean is configuring wrong mail
properties.
* [GERONIMO-1984] New Keystore portlet - Add Trust Certificate
throws exception
* [GERONIMO-1985] More then one configuration mananger was found
in kernel with daytrader-derby-jetty-streamer-client
* [GERONIMO-1996] Error during deployment may result in files not
being cleaned up properly
* [GERONIMO-2056] Plugins plugin.xml has hardcoded version numbers
* [GERONIMO-2058] Invalid gbean names in config.xml do not prevent
server starting or module starting
* [GERONIMO-2068] Upgrade tool should deal with gbean-name element
in gbean refs.
* [GERONIMO-2076] Must edit config.xml to provide custom plugin
install source
* [GERONIMO-2083] Use howl-logger-1.0.1-1.jar
* [GERONIMO-2100] Subject can remain attached to thread on return
from web app request, causing problems later on subsequent use of
that thread
* [GERONIMO-2104] NPE in maven1repo when bad directory name is listed
* [GERONIMO-2108] web app deployment fails with strange error if
geronimo-web.xml defines a message-destination
* [GERONIMO-2117] Remove deployer-log4j.properties files - they
are no longer used
* [GERONIMO-2119] new javamail components need scm tags in pom.xml
files.
* [GERONIMO-2125] Classpath entries in the web app archive META-
INF/MANIFEST.MF are not added to the wep app class path
* [GERONIMO-2130] javamail MimeUtilityTest fails on Mac OS/X
* [GERONIMO-2131] "Installed Configuration" message written using
System.out.println(..) instead of using the log
* [GERONIMO-2134] Shutdown error in ConfigurationClassLoader on
Java 5
* [GERONIMO-2136] Remove About icon and about page from console
* [GERONIMO-2138] Configuration jsp-examples-tomcat includes Jetty
dependencies
* [GERONIMO-2141] javamail providers component referencing non-
released version of activation specs.
* [GERONIMO-2164] Creating SQL- based security realm fails
* [GERONIMO-2165] Javamail provider component needs dependency
update to released 1.1 spec version for javamail 1.3.1 and activation.
* [GERONIMO-2171] some portions of a build still look at
cvs.apache.org/repository
* [GERONIMO-2175] etc/explicit_versions.properties should be
automatically generated (or made unecessary)
* [GERONIMO-2193] Build test failure in MimeUtilityTest on the Mac
* [GERONIMO-2195] SharedLib GBean fails to start if shared/lib and
shared/classes dirs are missing
* [GERONIMO-2197] NPE when the "edit" link is selected on the
Security Realms console page
* [GERONIMO-2198] CSSBean creates 2 unnecessary threads for every
instance.
* [GERONIMO-2199] Key portion of Geronimo-1145 appears have gotten
lost.
* [GERONIMO-2200] SMTP debug output echos portions of the output
twice.
* [GERONIMO-2202] Move to new Apache Maven 1 repo (repo/m1-
snapshot-repository
* [GERONIMO-2208] bad classpath in geronimo-deploy-jsr88-1.1.jar
* [GERONIMO-2213] Bug in ServerConstants cause NPE when geronimo-
version.properties is missing
* [GERONIMO-2214] Use m2 filtering to fill in values for geronimo-
version.propertes (and friends)
* [GERONIMO-2222] Application errors in static initialization
blocks during serialization of configuration during deployment due
to incorrect TCCL
* [GERONIMO-2234] User can lock the default keystore without
warning, making jetty server unusable
* [GERONIMO-2235] Locking default keystore results in
serialization error on tomcat termination
* [GERONIMO-2237] Filtering of springframework.org in
TomcatDeployer plan creates CNF Exceptions in Ears
* [GERONIMO-2241] Duplicate attributes created in config.xml for
gbean
* [GERONIMO-2243] GBean references do not trim space from
interface names (ref-type)
* [GERONIMO-2247] Apllications Portlets: "Restart" column does not
alternate background color
* [GERONIMO-2252] A locked key in a keystore can never be unlocked.
* [GERONIMO-2256] update m:checkout goal to use http to checkout
openejb
* [GERONIMO-2259] Redeploy fails when module is not running
* [GERONIMO-2260] Plugin export process loses data
* [GERONIMO-2261] Stopped module makes plugin eligible
* [GERONIMO-2268] Security Realm with more than one LoginModule
does not function as expected
* [GERONIMO-2269] Error after redeploy (with no version in module ID)
* [GERONIMO-2270] Redeploy broken in 1.1.1
* [GERONIMO-2272] Fix bad javamail version in
explicit_versions.properties
* [GERONIMO-2281] Deploy tool does not work (built from new m2 build)
* [GERONIMO-2285] Console Show Plan screens have bad EAR plan in
advice
* [GERONIMO-2295] Web app security constraint ignored if url-
pattern doesn't match servlet mapping exactly
* [GERONIMO-2298] geronimo-deploy-jsr88 jar is missing manifest
entries in m2 build
* [GERONIMO-2302] Unable to deploy from the console
* [GERONIMO-2304] Can't deploy on minimal assemblies produced with
m2 build
* [GERONIMO-2305]
geronimo.kernel.classloader.JarFileUrlStreamHandler fails with Trinidad
* [GERONIMO-2306] Add ASL info to LICENSE/NOTICE files in geronimo-
util jar file and BouncyCastle info to root directory LICENSE/NOTICE
* [GERONIMO-2309] MimeMessageTest can give failures for some
Windows configurations.
* [GERONIMO-2319] Unable to create a new OpenWire Listener from
console
* [GERONIMO-2321] DB Pool wizard allows "/" in the DB Pool name
* [GERONIMO-2325] unable to deploy from console with m2 build
* [GERONIMO-2326] unable to deploy a database pool
* [GERONIMO-2327] Need to encode colons for JACC web permissions
* [GERONIMO-2330] mismatched constructor gbean error message
doesn't actually show the expected classes
* [GERONIMO-2338] m2 assemblies have no way of getting rars/jars
that aren't car dependencies into the g repo
* [GERONIMO-2346] DB Info in console does not work and shows
'java.sql.SQLException' in the log
* [GERONIMO-2347] JMS Resources don't work in the console for
ActiveMQ
* [GERONIMO-2355] javamail MimeUtility tests will not work in all
code pages.
* [GERONIMO-2362] NPEs in DConfigBean/DDBean code
* [GERONIMO-2373] build broken with the removal of geronimo-
j2ee_1.4_spec from the specs
Tasks (16):
* [GERONIMO-851] Move Geronimo Build to M2 (Maven 2)
* [GERONIMO-1164] Java Adventure Builder Reference application
deployment
* [GERONIMO-1326] Remove ServiceMix modules / builder from 1.0 branch
* [GERONIMO-1458] Use JacORB IDL Compiler instead of Sun's idlj
* [GERONIMO-1514] Fix installer license statements
* [GERONIMO-1544] Installer - Straighten out licensing issues for
IzPack sub-components.
* [GERONIMO-1644] Migrate kernel module to Maven2
* [GERONIMO-1672] Module migration to Maven2: security
* [GERONIMO-1702] The latest maven 1 Build process
* [GERONIMO-2053] Restting Geronimo Build Tree for 1.2 Development
for post 1.1 activities
* [GERONIMO-2107] Begin reorganization of the javamail source tree.
* [GERONIMO-2161] [RTC] Remove Geronimo modules from
dependencyManagement in root pom.xml
* [GERONIMO-2162] Rename all modules to match the artifactId
defined in the module's pom.xml
* [GERONIMO-2174] Remove "modules/console-web"
* [GERONIMO-2331] Remove Maven 1 Artificats from Trunk and
Reorganize Directories to Conform to Maven 2 Layouts
* [GERONIMO-2334] Drop installer-support module (izpack installer
support)
Re: [Poll] Next release?
Posted by Gianny Damour <gi...@optusnet.com.au>.
On 09/09/2006, at 11:55 AM, Dain Sundstrom wrote:
> In an attempt to quantify our expectation about the next release
> from trunk, please rank the following items in importance to you:
>
> [ 2] Release Date
> [ 1] Feature Set
> [ 4] Release Name
> [ 3] Certification
>
It seems that the baton on Release Manager has already been handed
off :)
Thanks,
Gianny
Re: [Poll] Next release?
Posted by Matt Hogstrom <ma...@hogstrom.org>.
First off Dain, thanks for pulling all the info together. I didn't realize how much stuff was in
trunk right now. Now, to the topic at hand.
Dain Sundstrom wrote:
> In an attempt to quantify our expectation about the next release from
> trunk, please rank the following items in importance to you:
>
> [2] Release Date
> [1] Feature Set
> [3] Release Name
> [2] Certification
>
>
>
>
>
I'm not sure how to rank certification. I think its important to have a certified release on the
actual release date. I expect its not as critical for interim releases. I think I'm still using
Maven-1.1-beta-2 :)
--
Matt Hogstrom
Re: [Poll] Next release?
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 9/9/06, Dain Sundstrom <da...@iq80.com> wrote:
> [1] Release Date
> [2] Feature Set
> [3] Release Name
> [ALWAYS] Certification
where:
- Release Date (RD): It's the first item for it sets a final date so
people can add new features and fixes. The very first though was to
put Feature Set (FS) as the first, but then realized that having FS
without RD would not be beneficial.
- Release Notes can't be 5 until Geronimo doesn't support JEE 5 fully
(it should be easy to achieve, though ;-))
- Certifiaction is always a must - I'd vote against a release if it's
not j2ee 1.4 (or jee 5) certified.
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: [Poll] Next release?
Posted by Hernan Cunico <hc...@gmail.com>.
I'm gonna cheat a bit as I think that both release date and feature set
are equally important and one affects the other. Certification however
is a strong "1"
What do you mean by release name, _numbering_ ?
[2] Release Date
[2] Feature Set
[3] Release Name
[1] Certification
Cheers!
Hernan
Dain Sundstrom wrote:
> In an attempt to quantify our expectation about the next release from
> trunk, please rank the following items in importance to you:
>
> [ ] Release Date
> [ ] Feature Set
> [ ] Release Name
> [ ] Certification
>
>
>
Re: [Poll] Next release?
Posted by Kevan Miller <ke...@gmail.com>.
On Sep 8, 2006, at 9:55 PM, Dain Sundstrom wrote:
> In an attempt to quantify our expectation about the next release
> from trunk, please rank the following items in importance to you:
>
> [3 ] Release Date
> [2 ] Feature Set
> [4 ] Release Name
> [1] Certification
I don't view certification of a "release" as optional. I'd be
hesitant to deliver a non-certified milestone...
I do think that working to get trunk up to "releasable" standards is
a good thing. We're going to need to do that regardless... BTW, part
of this work should include the new Apache source header and
copyright notice policy -- http://www.apache.org/legal/src-headers.html.
Would be great to have an automated test for checking source headers,
LICENSE, and NOTICE files. Would hopefully avoid some of those last
minute release vote respins...
--kevan
Re: [Poll] Next release?
Posted by Joe Bohn <jo...@earthlink.net>.
Dain Sundstrom wrote:
> In an attempt to quantify our expectation about the next release from
> trunk, please rank the following items in importance to you:
>
> [3] Release Date
> [2] Feature Set
> [4] Release Name
> [1] Certification
>
I agree with Kevan that we can't ship a release now that isn't certified
so that isn't optional). I ranked these with that in mind. In other
words, I expect that we would remove/add function and possibly
compromise the date in order to ship a certified release.
Second to that I think we need to focus on what we need to be
competitive with a close second (3rd over all) on the date. Function
vs. date is always trade off depending upon the urgency of one or the
other with regard to our competitors. Finally, "what's in a name".
Joe
Re: [Poll] Next release?
Posted by David Blevins <da...@visi.com>.
On Sep 19, 2006, at 5:07 PM, David Jencks wrote:
> Oops, I missed replying.
>
> For me,
>
> 1- cert
> 2- release date
> 3- feature set
> 4- name
>
> I could probably be talked out of the release date priority if we
> are producing weekly certifiable builds and our build/tck process
> is working really smoothly.
>
> I'm really really really worried about the amount of development on
> trunk that has not had the tck run against it.
That pretty much echos my thoughts exactly.
-David
> thanks
> david jencks
>
> On Sep 19, 2006, at 4:58 PM, Dain Sundstrom wrote:
>
>> I only got a few responses, but we the results were almost unanimous
>> so I'm going to take this as a sign that most people agree with what
>> was already posted. If you do disagree with the poll results, please
>> speak up.
>>
>> RESULTS:
>>
>> [1] Certification
>> [2] Feature Set
>> [3] Release Date
>> [4] Release Name
>>
>> Certification is a requirement and timeline will be pushed to achieve
>> a desired feature set and no one seems to care what the release are
>> named :)
>>
>>
>> Based on this feed back, I will start another thread where we can
>> discuss the feature requirements for the next release. Again if you
>> disagree, please jump in now.
>>
>> Thanks for the feed back,
>>
>> -dain
>>
>> On 9/8/06, Dain Sundstrom <da...@iq80.com> wrote:
>>> In an attempt to quantify our expectation about the next release
>>> from
>>> trunk, please rank the following items in importance to you:
>>>
>>> [ ] Release Date
>>> [ ] Feature Set
>>> [ ] Release Name
>>> [ ] Certification
>>>
>>>
>>>
>
Re: [Poll] Next release?
Posted by David Jencks <da...@yahoo.com>.
Oops, I missed replying.
For me,
1- cert
2- release date
3- feature set
4- name
I could probably be talked out of the release date priority if we are
producing weekly certifiable builds and our build/tck process is
working really smoothly.
I'm really really really worried about the amount of development on
trunk that has not had the tck run against it.
thanks
david jencks
On Sep 19, 2006, at 4:58 PM, Dain Sundstrom wrote:
> I only got a few responses, but we the results were almost unanimous
> so I'm going to take this as a sign that most people agree with what
> was already posted. If you do disagree with the poll results, please
> speak up.
>
> RESULTS:
>
> [1] Certification
> [2] Feature Set
> [3] Release Date
> [4] Release Name
>
> Certification is a requirement and timeline will be pushed to achieve
> a desired feature set and no one seems to care what the release are
> named :)
>
>
> Based on this feed back, I will start another thread where we can
> discuss the feature requirements for the next release. Again if you
> disagree, please jump in now.
>
> Thanks for the feed back,
>
> -dain
>
> On 9/8/06, Dain Sundstrom <da...@iq80.com> wrote:
>> In an attempt to quantify our expectation about the next release from
>> trunk, please rank the following items in importance to you:
>>
>> [ ] Release Date
>> [ ] Feature Set
>> [ ] Release Name
>> [ ] Certification
>>
>>
>>
Re: [Poll] Next release?
Posted by Dain Sundstrom <ds...@gmail.com>.
I only got a few responses, but we the results were almost unanimous
so I'm going to take this as a sign that most people agree with what
was already posted. If you do disagree with the poll results, please
speak up.
RESULTS:
[1] Certification
[2] Feature Set
[3] Release Date
[4] Release Name
Certification is a requirement and timeline will be pushed to achieve
a desired feature set and no one seems to care what the release are
named :)
Based on this feed back, I will start another thread where we can
discuss the feature requirements for the next release. Again if you
disagree, please jump in now.
Thanks for the feed back,
-dain
On 9/8/06, Dain Sundstrom <da...@iq80.com> wrote:
> In an attempt to quantify our expectation about the next release from
> trunk, please rank the following items in importance to you:
>
> [ ] Release Date
> [ ] Feature Set
> [ ] Release Name
> [ ] Certification
>
>
>
[Poll] Next release?
Posted by Dain Sundstrom <da...@iq80.com>.
In an attempt to quantify our expectation about the next release from
trunk, please rank the following items in importance to you:
[ ] Release Date
[ ] Feature Set
[ ] Release Name
[ ] Certification
[Summary] Release Early, Release Often
Posted by Dain Sundstrom <da...@iq80.com>.
This has been a great discussion and a lot of important issues have
been raised. We don't seem to have a consensus just yet, but I think
we have made good progress toward one. I've snipped out the
highlights of the discussion below:
On Sep 6, 2006, at 12:40 PM, Joe Bohn wrote:
> I've heard several people talk about functions that they would like
> to see included in 1.2: Yoko, Java 5, JPA integration, clustering,
> GShell, pluggable JACC (may be already there), CMP for JPA,
> Usability improvements (esp. web console), performance
> improvements, etc... What of these capabilities do we as a
> community feel are critical to be competitive?
On Sep 6, 2006, at 3:49 PM, Jason Dillon wrote:
> I think that by releasing a 1.2-alpha, that we also start down the
> path of changing the perception of how quickly we release. The
> alpha can also serve to help us get some experience using the m2
> release plugin so that when it comes time for a non-alpha/beta
> release that we have confidence in the procedure... and this will
> give us time to make sure that we have the right configurations and
> setup to make a release with relative ease.
On Sep 7, 2006, at 6:22 AM, Dave Colasurdo wrote:
> IMHO, trunk is not currently in an Alpha state [....] It seems that
> trunk is currently in a pre-alpha state and I believe making an
> occasional unstable/nightly build available would allow users/
> developers to get familiar with the latest and greatest functions
> in trunk without giving the false impression that G1.2 is currently
> in Alpha state.
On Sep 7, 2006, at 11:57 AM, Hiram Chirino wrote:
> Lets stop trying to feature box so much and try to time box more.
> [....] If we don't release often then we can't tap our user
> community to help us QA and provide feedback more often.
On Sep 7, 2006, at 3:16 PM, Aaron Mulder wrote:
> I'd be happy to call it a pre-alpha or whatever.
On Sep 7, 2006, at 8:43 PM, Bruce Snyder wrote:
> forward progress and a visible roadmap are what users want to see.
> Right now Geronimo is headed pretty squarely down the path of
> updates every six months. IMO, we need to change that and feature
> packing every release is only going to keep things on that track.
On Sep 7, 2006, at 10:28 AM, David Jencks wrote:
> There are a bunch of jiras/bug fixes that still need to be forward
> ported to trunk, and the stuff in all_changes.log is still not
> addressed to a considerable extent.
And finally a comment from an actual user :)
On Sep 6, 2006, at 8:47 AM, Brian Chan wrote:
> I would love to see that as well. I'm waiting on a few fixes (ejb
> compile leaking) to get on a stable Geronimo release so we can
> release Liferay 4.2.0 with Geronimo on the enterprise level (thanks
> to Jeff Grenender for that). Otherwise, will just have to go with a
> snapshot which doesn't look as good.
I'm going to start a new thread to attempt to gain a consensus on 1.2
and a separate one for the issue David Jencks raised about dead-1.2.
-dain
Re: Release Early, Release Often
Posted by ja...@gmail.com.
Why would we make a 1.1.2 from trunk? That seems rather odd todo since 1.1.x is on its own branch. If we did, then we would have another huge merge to perform.
Just release it as 1.2
--jason
-----Original Message-----
From: "Paul McMahan" <pa...@gmail.com>
Date: Thu, 7 Sep 2006 18:11:04
To:dev@geronimo.apache.org
Subject: Re: Release Early, Release Often
Wow I didn't realize trunk had accumulated so much stuff. I like the
mantra Dain used in the subject line, but understand the concerns
about calling what's in trunk right now version 1.2 without some
additional rounding. Should we discuss cutting and releasing a 1.1.2
branch off of trunk instead? Or is there already too much stuff in
there to call it a 1.1.x release?
Paul
On 9/7/06, Dain Sundstrom <da...@iq80.com> wrote:
> I spent a long time looking through JIRA and the svn log comments and
> there are a lot of changes in trunk already. Just to start with we
> have 290 JIRAs closed against 1.2 and there are a few big changes
> that don't have JIRAs (these were mostly my fault :). I whipped
> together a preliminary roadmap report using swizzle, but as you will
> see many of the issues are classified incorrectly.
>
> Anyway, here is a list of the items we have completed in trunk
> already. Did I miss any completed work? How do you want to proceed?
>
> -dain
>
>
>
> New Features (7):
>
> * [NOJIRA] Upgrade ActiveMQ from 3.2 to 4.1 (see http://
> incubator.apache.org/activemq for features)
> * [NOJIRA] Add Maven 2 deployment tools
> * [GERONIMO-1133] UUID primary key generator
> * [GERONIMO-1192] Installer should create a config.xml for the
> target install
> * [GERONIMO-1259] reduce the size of the combined deployment plan:
> package deployment plans in a jar and pass this jar to the deployer
> * [GERONIMO-1573] Spring integration -- wrap our components in
> spring interfaces
> * [GERONIMO-1593] Add SMTP Authentication and STARTTLS support.
> * [GERONIMO-2071] Move Geronimo build to M2 (new 1.2 trunk)
> * [GERONIMO-2132] Move activemq gbean integration modules from
> ActiveMQ to Geronimo
>
> Major Improvements (21):
>
> *[ NOJIRA] Simplify EJB container configuration
> * [GERONIMO-790] JettyModuleBuilder should use references to
> templates, not their names
> * [GERONIMO-1163] improve jmx debug console
> * [GERONIMO-1194] Installer should only install packs(features)
> selected at install time
> * [GERONIMO-1278] Upgrade to XML Beans 2.1.0 from 2.0.0
> * [GERONIMO-1335] Create issues for making the plugins run in more
> ways
> * [GERONIMO-1401] Updates to BUILDING.txt about the last changes
> to the build process
> * [GERONIMO-1434] Allow GBeans to be bound into a component's
> java:comp/env namespace
> * [GERONIMO-1527] InternetAddress does not properly implement
> address parsing.
> * [GERONIMO-1554] Installer - Move advanced features to non-
> default installer path (simplify default installation)
> * [GERONIMO-1563] [RTC] Make the JACC implementation pluggable
> * [GERONIMO-1613] Eliminate unncessary dependencies to reduce
> assemnbly footprint size
> * [GERONIMO-1647] Enabling access to session id on Tomcat
> * [GERONIMO-1651] Complete implementation of javamail MimeMessage
> and MimeUtil classes.
> * [GERONIMO-1772] Application class loader should not see server
> classes
> * [GERONIMO-1960] Reject invalid GBean references at deployment time
> * [GERONIMO-2092] Modules migration to M2
> * [GERONIMO-2152] Update for new OpenEJB 2.2
> * [GERONIMO-2224] Add a geronimo specific system property for
> controlling dom, sax, and transformer creation
> * [GERONIMO-2277] Remove TransactionContextManager
> * [GERONIMO-2300] Use jar or assembly plugin to generate classpath/
> manifest bits for stuff in bin/*
> * [GERONIMO-2374] use junit decorators with selenium
>
> Critical Bug Fixes (16):
>
> * [GERONIMO-1176] Bad "resource" reference is not caught at
> deployment time
> * [GERONIMO-1196] Keystore portlet: Viewing trusted certificate
> results in an error
> * [GERONIMO-1307] JMX connector doesn't shut down cleanly
> * [GERONIMO-1433] Security vulnerability of WEB-INF contents on
> windows platforms
> * [GERONIMO-1455] Start of CAR does not load and start its GBeans
> * [GERONIMO-1480] Cross context include does not set jacc
> contextID for 2nd web app. (Tomcat only)
> * [GERONIMO-1596] Repeated interface in JMS connection factory
> plan causes deployment failure
> * [GERONIMO-1599] HOWLLog throws NPE because XidFactory is missing
> * [GERONIMO-1649] Invalid deployment descriptor error when
> deploying an EJB 2.0 MDB
> * [GERONIMO-2058] Invalid gbean names in config.xml do not prevent
> server starting or module starting
> * [GERONIMO-2100] Subject can remain attached to thread on return
> from web app request, causing problems later on subsequent use of
> that thread
> * [GERONIMO-2222] Application errors in static initialization
> blocks during serialization of configuration during deployment due
> to incorrect TCCL
> * [GERONIMO-2234] User can lock the default keystore without
> warning, making jetty server unusable
> * [GERONIMO-2237] Filtering of springframework.org in
> TomcatDeployer plan creates CNF Exceptions in Ears
> * [GERONIMO-2270] Redeploy broken in 1.1.1
> * [GERONIMO-2305]
> geronimo.kernel.classloader.JarFileUrlStreamHandler fails with Trinidad
>
>
Re: Release Early, Release Often
Posted by Paul McMahan <pa...@gmail.com>.
Wow I didn't realize trunk had accumulated so much stuff. I like the
mantra Dain used in the subject line, but understand the concerns
about calling what's in trunk right now version 1.2 without some
additional rounding. Should we discuss cutting and releasing a 1.1.2
branch off of trunk instead? Or is there already too much stuff in
there to call it a 1.1.x release?
Paul
On 9/7/06, Dain Sundstrom <da...@iq80.com> wrote:
> I spent a long time looking through JIRA and the svn log comments and
> there are a lot of changes in trunk already. Just to start with we
> have 290 JIRAs closed against 1.2 and there are a few big changes
> that don't have JIRAs (these were mostly my fault :). I whipped
> together a preliminary roadmap report using swizzle, but as you will
> see many of the issues are classified incorrectly.
>
> Anyway, here is a list of the items we have completed in trunk
> already. Did I miss any completed work? How do you want to proceed?
>
> -dain
>
>
>
> New Features (7):
>
> * [NOJIRA] Upgrade ActiveMQ from 3.2 to 4.1 (see http://
> incubator.apache.org/activemq for features)
> * [NOJIRA] Add Maven 2 deployment tools
> * [GERONIMO-1133] UUID primary key generator
> * [GERONIMO-1192] Installer should create a config.xml for the
> target install
> * [GERONIMO-1259] reduce the size of the combined deployment plan:
> package deployment plans in a jar and pass this jar to the deployer
> * [GERONIMO-1573] Spring integration -- wrap our components in
> spring interfaces
> * [GERONIMO-1593] Add SMTP Authentication and STARTTLS support.
> * [GERONIMO-2071] Move Geronimo build to M2 (new 1.2 trunk)
> * [GERONIMO-2132] Move activemq gbean integration modules from
> ActiveMQ to Geronimo
>
> Major Improvements (21):
>
> *[ NOJIRA] Simplify EJB container configuration
> * [GERONIMO-790] JettyModuleBuilder should use references to
> templates, not their names
> * [GERONIMO-1163] improve jmx debug console
> * [GERONIMO-1194] Installer should only install packs(features)
> selected at install time
> * [GERONIMO-1278] Upgrade to XML Beans 2.1.0 from 2.0.0
> * [GERONIMO-1335] Create issues for making the plugins run in more
> ways
> * [GERONIMO-1401] Updates to BUILDING.txt about the last changes
> to the build process
> * [GERONIMO-1434] Allow GBeans to be bound into a component's
> java:comp/env namespace
> * [GERONIMO-1527] InternetAddress does not properly implement
> address parsing.
> * [GERONIMO-1554] Installer - Move advanced features to non-
> default installer path (simplify default installation)
> * [GERONIMO-1563] [RTC] Make the JACC implementation pluggable
> * [GERONIMO-1613] Eliminate unncessary dependencies to reduce
> assemnbly footprint size
> * [GERONIMO-1647] Enabling access to session id on Tomcat
> * [GERONIMO-1651] Complete implementation of javamail MimeMessage
> and MimeUtil classes.
> * [GERONIMO-1772] Application class loader should not see server
> classes
> * [GERONIMO-1960] Reject invalid GBean references at deployment time
> * [GERONIMO-2092] Modules migration to M2
> * [GERONIMO-2152] Update for new OpenEJB 2.2
> * [GERONIMO-2224] Add a geronimo specific system property for
> controlling dom, sax, and transformer creation
> * [GERONIMO-2277] Remove TransactionContextManager
> * [GERONIMO-2300] Use jar or assembly plugin to generate classpath/
> manifest bits for stuff in bin/*
> * [GERONIMO-2374] use junit decorators with selenium
>
> Critical Bug Fixes (16):
>
> * [GERONIMO-1176] Bad "resource" reference is not caught at
> deployment time
> * [GERONIMO-1196] Keystore portlet: Viewing trusted certificate
> results in an error
> * [GERONIMO-1307] JMX connector doesn't shut down cleanly
> * [GERONIMO-1433] Security vulnerability of WEB-INF contents on
> windows platforms
> * [GERONIMO-1455] Start of CAR does not load and start its GBeans
> * [GERONIMO-1480] Cross context include does not set jacc
> contextID for 2nd web app. (Tomcat only)
> * [GERONIMO-1596] Repeated interface in JMS connection factory
> plan causes deployment failure
> * [GERONIMO-1599] HOWLLog throws NPE because XidFactory is missing
> * [GERONIMO-1649] Invalid deployment descriptor error when
> deploying an EJB 2.0 MDB
> * [GERONIMO-2058] Invalid gbean names in config.xml do not prevent
> server starting or module starting
> * [GERONIMO-2100] Subject can remain attached to thread on return
> from web app request, causing problems later on subsequent use of
> that thread
> * [GERONIMO-2222] Application errors in static initialization
> blocks during serialization of configuration during deployment due
> to incorrect TCCL
> * [GERONIMO-2234] User can lock the default keystore without
> warning, making jetty server unusable
> * [GERONIMO-2237] Filtering of springframework.org in
> TomcatDeployer plan creates CNF Exceptions in Ears
> * [GERONIMO-2270] Redeploy broken in 1.1.1
> * [GERONIMO-2305]
> geronimo.kernel.classloader.JarFileUrlStreamHandler fails with Trinidad
>
>
Re: Release Early, Release Often
Posted by John Sisson <jr...@gmail.com>.
Hernan Cunico wrote:
> We already have some "structure" for monitoring (or better trying to
> monitor) the project development status
> http://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Development+Status
>
>
> Any ideas how we could reuse this info/templates?
>
> Would it be better to have the "Apache Geronimo Development Status"
> moved under "Apache Geronimo Development"?
>
> What would help us to stay on track
>
I agree it would be helpful to track progress using the report card and
package tracking wiki pages from the link above, possibly updated with
links to the appropriate JIRAs.
John
> Cheers!
> Hernan
>
> Bruce Snyder wrote:
>> On 9/7/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
>>> I'm a big believer that 1.3 will have a ton of nice features! If you
>>> release it, users will use it :) I don't think we need to feature
>>> pack every release.
>>>
>>> It seems to me we spent a bunch of time feature packing a 1.1.x
>>> release. If we would do that to trunk instead, our 1.n releases would
>>> be more impressive.
>>
>> Agreed - forward progress and a visible roadmap are what users want to
>> see. Right now Geronimo is headed pretty squarely down the path of
>> updates every six months. IMO, we need to change that and feature
>> packing every release is only going to keep things on that track.
>>
>> Bruce
>
Re: Release Early, Release Often
Posted by Hernan Cunico <hc...@gmail.com>.
For Geronimo v1.1 we gathered a list with the user requirements and made
it available in the wiki.
I would propose we do the same for the next release (v1.2 for now) and
include, along with the user requirements, the features we would like to
have. Yup, that's the roadmap we are all talking about.
Here is a template based on what we had for v1.1
http://cwiki.apache.org/GMOxDEV/geronimo-v12-user-requirements.html
If we want to release early/often then we could add a tentative target
date per feature, not necessarily release, just feature added to trunk.
I know adding dates is not too appealing but if we want to deliver often
on regular basis we need to somehow time-box the releases.
There is already a discussion about uncertified weekly builds but, how
often do we want to deliver a fully certified release?
We already have some "structure" for monitoring (or better trying to
monitor) the project development status
http://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Development+Status
Any ideas how we could reuse this info/templates?
Would it be better to have the "Apache Geronimo Development Status"
moved under "Apache Geronimo Development"?
What would help us to stay on track
Cheers!
Hernan
Bruce Snyder wrote:
> On 9/7/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
>> I'm a big believer that 1.3 will have a ton of nice features! If you
>> release it, users will use it :) I don't think we need to feature
>> pack every release.
>>
>> It seems to me we spent a bunch of time feature packing a 1.1.x
>> release. If we would do that to trunk instead, our 1.n releases would
>> be more impressive.
>
> Agreed - forward progress and a visible roadmap are what users want to
> see. Right now Geronimo is headed pretty squarely down the path of
> updates every six months. IMO, we need to change that and feature
> packing every release is only going to keep things on that track.
>
> Bruce
Re: Release Early, Release Often
Posted by Bruce Snyder <br...@gmail.com>.
On 9/7/06, Hiram Chirino <hi...@hiramchirino.com> wrote:
> I'm a big believer that 1.3 will have a ton of nice features! If you
> release it, users will use it :) I don't think we need to feature
> pack every release.
>
> It seems to me we spent a bunch of time feature packing a 1.1.x
> release. If we would do that to trunk instead, our 1.n releases would
> be more impressive.
Agreed - forward progress and a visible roadmap are what users want to
see. Right now Geronimo is headed pretty squarely down the path of
updates every six months. IMO, we need to change that and feature
packing every release is only going to keep things on that track.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
Re: Release Early, Release Often
Posted by Hiram Chirino <hi...@hiramchirino.com>.
I'm a big believer that 1.3 will have a ton of nice features! If you
release it, users will use it :) I don't think we need to feature
pack every release.
It seems to me we spent a bunch of time feature packing a 1.1.x
release. If we would do that to trunk instead, our 1.n releases would
be more impressive.
On 9/7/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> And I guess to return to the original subject -- I'd be fine release
> something like this as a 1.n.m+1 release -- it has plenty to be "an
> advance". But I think there's enough incompatibility with 1.1.x that
> I don't think it would make a good 1.1.2. I wish we already had a
> solid 1.2 release down so we could say this is a great looking 1.2.1
> release, you know? I'm not so sure it's exciting as a 1.2 release on
> its own.
>
> But I'd be happy to call it a pre-alpha or whatever.
>
> Thanks,
> Aaron
>
> On 9/7/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> > On 9/7/06, Jason Dillon <ja...@planet57.com> wrote:
> > > ActiveMQ 4.1 is a massive upgrade (a really good thing) from the
> > > previous offering in G 1.x
> >
> > It is a good upgrade, but looking over that list, it's practically the
> > only big advance for a typical user, and that's assuming they care
> > that much about JMS. I wish we had more big bang features for our
> > next 1.x release (especially EE 5 stuff -- where's the web and web
> > services integration? How is OpenEJB 3 coming? What about XBean
> > integration? Retrotranslator? Yoko?). Also, a fair amount of
> > non-new-feature items on the list were included in 1.1.1...
> >
> > Thanks,
> > Aaron
> >
> > > On Sep 7, 2006, at 2:52 PM, Hiram Chirino wrote:
> > >
> > > > On 9/7/06, Dain Sundstrom <da...@iq80.com> wrote:
> > > >> * [NOJIRA] Upgrade ActiveMQ from 3.2 to 4.1 (see http://
> > > >> incubator.apache.org/activemq for features)
> > > >
> > > > You can find a list of new features in ActiveMQ 4.0 here:
> > > > http://activemq.com/site/changes-in-40.html
> > > > and the new features in 4.1 here:
> > > > http://activemq.com/site/new-features-in-41.html
> > > >
> > > > --
> > > > Regards,
> > > > Hiram
> > > >
> > > > Blog: http://hiramchirino.com
> > >
> > >
> >
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Release Early, Release Often
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
And I guess to return to the original subject -- I'd be fine release
something like this as a 1.n.m+1 release -- it has plenty to be "an
advance". But I think there's enough incompatibility with 1.1.x that
I don't think it would make a good 1.1.2. I wish we already had a
solid 1.2 release down so we could say this is a great looking 1.2.1
release, you know? I'm not so sure it's exciting as a 1.2 release on
its own.
But I'd be happy to call it a pre-alpha or whatever.
Thanks,
Aaron
On 9/7/06, Aaron Mulder <am...@alumni.princeton.edu> wrote:
> On 9/7/06, Jason Dillon <ja...@planet57.com> wrote:
> > ActiveMQ 4.1 is a massive upgrade (a really good thing) from the
> > previous offering in G 1.x
>
> It is a good upgrade, but looking over that list, it's practically the
> only big advance for a typical user, and that's assuming they care
> that much about JMS. I wish we had more big bang features for our
> next 1.x release (especially EE 5 stuff -- where's the web and web
> services integration? How is OpenEJB 3 coming? What about XBean
> integration? Retrotranslator? Yoko?). Also, a fair amount of
> non-new-feature items on the list were included in 1.1.1...
>
> Thanks,
> Aaron
>
> > On Sep 7, 2006, at 2:52 PM, Hiram Chirino wrote:
> >
> > > On 9/7/06, Dain Sundstrom <da...@iq80.com> wrote:
> > >> * [NOJIRA] Upgrade ActiveMQ from 3.2 to 4.1 (see http://
> > >> incubator.apache.org/activemq for features)
> > >
> > > You can find a list of new features in ActiveMQ 4.0 here:
> > > http://activemq.com/site/changes-in-40.html
> > > and the new features in 4.1 here:
> > > http://activemq.com/site/new-features-in-41.html
> > >
> > > --
> > > Regards,
> > > Hiram
> > >
> > > Blog: http://hiramchirino.com
> >
> >
>
Re: Release Early, Release Often
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 9/7/06, Jason Dillon <ja...@planet57.com> wrote:
> ActiveMQ 4.1 is a massive upgrade (a really good thing) from the
> previous offering in G 1.x
It is a good upgrade, but looking over that list, it's practically the
only big advance for a typical user, and that's assuming they care
that much about JMS. I wish we had more big bang features for our
next 1.x release (especially EE 5 stuff -- where's the web and web
services integration? How is OpenEJB 3 coming? What about XBean
integration? Retrotranslator? Yoko?). Also, a fair amount of
non-new-feature items on the list were included in 1.1.1...
Thanks,
Aaron
> On Sep 7, 2006, at 2:52 PM, Hiram Chirino wrote:
>
> > On 9/7/06, Dain Sundstrom <da...@iq80.com> wrote:
> >> * [NOJIRA] Upgrade ActiveMQ from 3.2 to 4.1 (see http://
> >> incubator.apache.org/activemq for features)
> >
> > You can find a list of new features in ActiveMQ 4.0 here:
> > http://activemq.com/site/changes-in-40.html
> > and the new features in 4.1 here:
> > http://activemq.com/site/new-features-in-41.html
> >
> > --
> > Regards,
> > Hiram
> >
> > Blog: http://hiramchirino.com
>
>
Re: Release Early, Release Often
Posted by Jason Dillon <ja...@planet57.com>.
ActiveMQ 4.1 is a massive upgrade (a really good thing) from the
previous offering in G 1.x
--jason
On Sep 7, 2006, at 2:52 PM, Hiram Chirino wrote:
> On 9/7/06, Dain Sundstrom <da...@iq80.com> wrote:
>> * [NOJIRA] Upgrade ActiveMQ from 3.2 to 4.1 (see http://
>> incubator.apache.org/activemq for features)
>
> You can find a list of new features in ActiveMQ 4.0 here:
> http://activemq.com/site/changes-in-40.html
> and the new features in 4.1 here:
> http://activemq.com/site/new-features-in-41.html
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
Re: Release Early, Release Often
Posted by Hiram Chirino <hi...@hiramchirino.com>.
On 9/7/06, Dain Sundstrom <da...@iq80.com> wrote:
> * [NOJIRA] Upgrade ActiveMQ from 3.2 to 4.1 (see http://
> incubator.apache.org/activemq for features)
You can find a list of new features in ActiveMQ 4.0 here:
http://activemq.com/site/changes-in-40.html
and the new features in 4.1 here:
http://activemq.com/site/new-features-in-41.html
--
Regards,
Hiram
Blog: http://hiramchirino.com
Re: Release Early, Release Often
Posted by Dain Sundstrom <da...@iq80.com>.
I spent a long time looking through JIRA and the svn log comments and
there are a lot of changes in trunk already. Just to start with we
have 290 JIRAs closed against 1.2 and there are a few big changes
that don't have JIRAs (these were mostly my fault :). I whipped
together a preliminary roadmap report using swizzle, but as you will
see many of the issues are classified incorrectly.
Anyway, here is a list of the items we have completed in trunk
already. Did I miss any completed work? How do you want to proceed?
-dain
New Features (7):
* [NOJIRA] Upgrade ActiveMQ from 3.2 to 4.1 (see http://
incubator.apache.org/activemq for features)
* [NOJIRA] Add Maven 2 deployment tools
* [GERONIMO-1133] UUID primary key generator
* [GERONIMO-1192] Installer should create a config.xml for the
target install
* [GERONIMO-1259] reduce the size of the combined deployment plan:
package deployment plans in a jar and pass this jar to the deployer
* [GERONIMO-1573] Spring integration -- wrap our components in
spring interfaces
* [GERONIMO-1593] Add SMTP Authentication and STARTTLS support.
* [GERONIMO-2071] Move Geronimo build to M2 (new 1.2 trunk)
* [GERONIMO-2132] Move activemq gbean integration modules from
ActiveMQ to Geronimo
Major Improvements (21):
*[ NOJIRA] Simplify EJB container configuration
* [GERONIMO-790] JettyModuleBuilder should use references to
templates, not their names
* [GERONIMO-1163] improve jmx debug console
* [GERONIMO-1194] Installer should only install packs(features)
selected at install time
* [GERONIMO-1278] Upgrade to XML Beans 2.1.0 from 2.0.0
* [GERONIMO-1335] Create issues for making the plugins run in more
ways
* [GERONIMO-1401] Updates to BUILDING.txt about the last changes
to the build process
* [GERONIMO-1434] Allow GBeans to be bound into a component's
java:comp/env namespace
* [GERONIMO-1527] InternetAddress does not properly implement
address parsing.
* [GERONIMO-1554] Installer - Move advanced features to non-
default installer path (simplify default installation)
* [GERONIMO-1563] [RTC] Make the JACC implementation pluggable
* [GERONIMO-1613] Eliminate unncessary dependencies to reduce
assemnbly footprint size
* [GERONIMO-1647] Enabling access to session id on Tomcat
* [GERONIMO-1651] Complete implementation of javamail MimeMessage
and MimeUtil classes.
* [GERONIMO-1772] Application class loader should not see server
classes
* [GERONIMO-1960] Reject invalid GBean references at deployment time
* [GERONIMO-2092] Modules migration to M2
* [GERONIMO-2152] Update for new OpenEJB 2.2
* [GERONIMO-2224] Add a geronimo specific system property for
controlling dom, sax, and transformer creation
* [GERONIMO-2277] Remove TransactionContextManager
* [GERONIMO-2300] Use jar or assembly plugin to generate classpath/
manifest bits for stuff in bin/*
* [GERONIMO-2374] use junit decorators with selenium
Critical Bug Fixes (16):
* [GERONIMO-1176] Bad "resource" reference is not caught at
deployment time
* [GERONIMO-1196] Keystore portlet: Viewing trusted certificate
results in an error
* [GERONIMO-1307] JMX connector doesn't shut down cleanly
* [GERONIMO-1433] Security vulnerability of WEB-INF contents on
windows platforms
* [GERONIMO-1455] Start of CAR does not load and start its GBeans
* [GERONIMO-1480] Cross context include does not set jacc
contextID for 2nd web app. (Tomcat only)
* [GERONIMO-1596] Repeated interface in JMS connection factory
plan causes deployment failure
* [GERONIMO-1599] HOWLLog throws NPE because XidFactory is missing
* [GERONIMO-1649] Invalid deployment descriptor error when
deploying an EJB 2.0 MDB
* [GERONIMO-2058] Invalid gbean names in config.xml do not prevent
server starting or module starting
* [GERONIMO-2100] Subject can remain attached to thread on return
from web app request, causing problems later on subsequent use of
that thread
* [GERONIMO-2222] Application errors in static initialization
blocks during serialization of configuration during deployment due
to incorrect TCCL
* [GERONIMO-2234] User can lock the default keystore without
warning, making jetty server unusable
* [GERONIMO-2237] Filtering of springframework.org in
TomcatDeployer plan creates CNF Exceptions in Ears
* [GERONIMO-2270] Redeploy broken in 1.1.1
* [GERONIMO-2305]
geronimo.kernel.classloader.JarFileUrlStreamHandler fails with Trinidad
Re: Release Early, Release Often
Posted by Jason Dillon <ja...@planet57.com>.
I think that trunk might be good enough for an alpha or beta pre-
release of 1.2.
I would love to see use release early and often...
--jason
On Sep 5, 2006, at 1:40 PM, Dain Sundstrom wrote:
> According to our STATUS file, our last feature release (1.1) was on
> 2006-06-26 which is about 2.5 months ago. I'm not sure exactly
> what we have in trunk right now, but I'd guess we most likely have
> enough to do a release right now. I'm going to spend a few hours
> today browsing the JIRAs and SVN logs and compile a list of the
> features we have in trunk right now. Anyways, I'll let you know
> what I find and we can figure out what we want to do.
>
> Thanks,
>
> -dain