excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shash Chatterjee <sh...@badfw.org>
Subject Excalibur Release Plan (was: Re: Release excalibur-logger, -pool, -component.)
Date Sun, 10 Apr 2005 19:04:23 GMT

>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

Mime
View raw message