Excalibur Release Plan (was: Re: Release excalibur-logger, -pool, -component.)

[Shash Chatterjee]

We should provide at least one release candidate distribution as source and binary before any final release. General workflow for a release looks like: 1. Someone steps up as "Release Manager" to spearhead the release yours truly 2. Cleans up the code and identifies a revision number for an RC release I have gone through and updated all the POMs.  Everything builds and whatever tests are there run fine. As it turned out, latest FW is 4.3 (not 4.2.0).  At  the moment I cannot check anything in, evidently I lack "karma". Here's the list of the new (to be released) versions (I am proposing releasing some deprecated ones as well, just to get everything up to FW 4.3 and to tag the release): avalon-framework-api - 4.3 avalon-framework-impl - 4.3 avalon-logkit - 2.1 excalibur-component - 1.3 excalibur-component-examples - 1.0 excalibur-component-tests - 1.3 excalibur-datasource - 1.3 excalibur-event-{api,impl} - 2.1 excalibur-fortress-{bean,cli,container-api,container-impl,container-test,examples,meta,migration,platform,servlet,testcase} - 1.2 excalibur-instrument-{api,client,mgr-api,mgr-http,mgr-impl) - 1.2 excalibur-lifecycle-{api,impl} - 1.2 excalibur-logger - 1.2 excalibur-monitor - 1.2 excalibur-pool-{api,impl,instrumented} - 2.1 excalibur-sourceresolve - 2.1 excalibur-store - 1.2 excalibur-testcase - 3.1 excalibur-thread-{api,impl,instrumented} - 2.1 excalibur-xmlutil - 1.2 cornerstone-connection-{api,impl} - 2.1 cornerstone-datasources-{api,impl} - 2.1 cornerstone-scheduler-{api,impl} - 2.1 cornerstone-sockets-{api,impl} - 2.1 cornerstone-store-{api,impl} - 2.1 cornerstone-threads-{api,impl,tutorial} - 2.1 maven-fortress-plugin - 0.2 I have changed all the 3rd-party dependencies as follows: ant - 1.6.2 bcel - 5.1 commons-beanutils - 1.7.0 commons-collections - 3.1 commons-httpclient - 2.0.2 commons-logging - 1.0.4 commons-vfs - 20050307052300 concurrent - 1.3.4 jisp - 2.5.1 junit - 3.8.1 juintperf - 1.8.1 hsqldb - 1.7.1 (1.7.3 causes test failure...need to chase) log4j - 1.2.8 qdox - 1.5 servletapi - 2.3 xalan - 2.6.0 xerces - 2.4.0 xml-apis - 2.0.2 3. PMC signs off on a RC release I guess this can happen after I checkin my changes and everybody gets a chance to try from SVN.   Given the number of modules, it'd be nice if I/we didn't have to go change all the plugin.xml-s for the currentVersion and then everything else to depend on the changed version numbes for every RC and then the release cycle.  Any ideas? One thought was to change the hard-coded version numbers to Maven properties, and then define all the versions in build.properties in excalibur-trunk (i.e have one file to control everything).  The problem is I don't know how the POM will look when deployed to a remote Maven repo. 4. Release Manager publishes the RC release Do I need to tag SVN for this? I am assuming I do. Unless someone tells me how to do this easily for all the modules, I think I am going to write something in Jelly for Maven to allow use of the multiproject plugin, derive a tag from currentVersion and apply the tag (doesn't look like Maven's scm, repository, release plugins do what we need).  BTW, project-common.xml is evil for this purpose....need to tag the parent dir even though only a nested dir/project is being released. Do we need to do source releases for the RC-s? Shash