On Sun, 2006-01-22 at 19:22 -0500, Rahul Akolkar wrote: > On 1/22/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Author: rdonkin > > Date: Sun Jan 22 15:26:41 2006 > > New Revision: 371420 > > > > URL: http://svn.apache.org/viewcvs?rev=371420&view=rev > > Log: > > Upgraded version number in preparation for cutting first candidate > > > > Modified: > > jakarta/commons/proper/logging/trunk/build.xml > > jakarta/commons/proper/logging/trunk/project.xml > > > > Modified: jakarta/commons/proper/logging/trunk/build.xml > > URL: > > http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/build.xml?rev=371420&r1=371419&r2=371420&view=diff > > ============================================================================== > > --- jakarta/commons/proper/logging/trunk/build.xml (original) > > +++ jakarta/commons/proper/logging/trunk/build.xml Sun Jan 22 15:26:41 2006 > > @@ -87,7 +87,7 @@ > > <property name="component.title" value="Logging Wrapper Library"/> > > > > <!-- The current version number of this component --> > > - <property name="component.version" value="1.1-dev"/> > > + <property name="component.version" value="1.1"/> > > > <snip/> > > I would not expect a value of "1.1" to show up here unless you're > actively cutting a release ATM, which seems improbable. Did you mean > "1.1-RC1" or something to that effect? TIA for clarifying.
i was planning to use a variation of the httpd/tomcat/struts style release process. my reason is that JCL is *very* widely used and any mistakes will be *very* bad news. this release process works a little differently to the releases usually cut here in the commons. basically, the same artifact is voted from RC->alpha->beta->final. this has advantages since the JCL release process cannot be fully automated (it needs two different JVM versions). i'll post more on this tomorrow. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
