Re: Release Early, Release Often
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 <[EMAIL PROTECTED]> 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
[Summary] Release Early, Release Often
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
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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
Re: Release Early, Release Often
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 <[EMAIL PROTECTED]> 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
I think it is good idea! ;)2006/9/7, Jeff Genender <[EMAIL PROTECTED]>: 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
On 9/7/06, Hiram Chirino <[EMAIL PROTECTED]> 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)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://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
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > On 9/7/06, Jason Dillon <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]> wrote: On 9/7/06, Jason Dillon <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
On 9/7/06, Jason Dillon <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]> 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-] 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
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 <[EMAIL PROTECTED]> 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
On 9/7/06, Dain Sundstrom <[EMAIL PROTECTED]> 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
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
Re: Release Early, Release Often
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-] 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
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 <[EMAIL PROTECTED]> 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 >>>>
Re: Release Early, Release Often
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 f
Re: Release Early, Release Often
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 <[EMAIL PROTECTED]> 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. >
Re: Release Early, Release Often
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
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
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
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
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
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
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
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
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
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 <[EMAIL PROTECTED]> 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
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
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
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.- BrianOn 9/5/06 6:17 PM, Jason Dillon <[EMAIL PROTECTED]> wrote: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--Brian ChanChief Executive OfficerLiferay, LLCEnterprise. Open Source. For Life.
Re: Release Early, Release Often
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
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
