You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Dain Sundstrom <da...@iq80.com> on 2006/12/12 21:52:00 UTC

Proposed version/spec release process

Kevan asked me to go over the development/release process used when  
we have a single version number.

1 Make a development module in specs/trunk
   [Maintince] svn cp specs/tags/<artifactId>-<latestVersion> specs/ 
trunk/<artifactId>
   [New] make a new mvn module at specs/trunk/<artifactId>

2 Make changes
   There is no need to update inner spec depenencies since all will  
be marked as scope provided in the pom, so we don't get transitive  
problems.

3 Vote and Release
   update pom version
   create jars
   vote
   publish
   svn mv specs/trunk/<artifactId> specs/tags/<artifactId>-<version>

Alternatively, we can use the release plugin but the release plugin  
means we can't vote on the final jars since it automatically  
publishes to the final repository.

BTW, I am willing to be spec release manager using this process in  
perpetuity.

-dain


Re: Proposed version/spec release process

Posted by Dain Sundstrom <da...@iq80.com>.
On Dec 12, 2006, at 5:32 PM, Kevan Miller wrote:

> On Dec 12, 2006, at 3:52 PM, Dain Sundstrom wrote:
>
>> Kevan asked me to go over the development/release process used  
>> when we have a single version number.
>>
>> 1 Make a development module in specs/trunk
>>   [Maintince] svn cp specs/tags/<artifactId>-<latestVersion> specs/ 
>> trunk/<artifactId>
>>   [New] make a new mvn module at specs/trunk/<artifactId>
>>
>> 2 Make changes
>>   There is no need to update inner spec depenencies since all will  
>> be marked as scope provided in the pom, so we don't get transitive  
>> problems.
>>
>> 3 Vote and Release
>>   update pom version
>>   create jars
>>   vote
>>   publish
>>   svn mv specs/trunk/<artifactId> specs/tags/<artifactId>-<version>
>>
>> Alternatively, we can use the release plugin but the release  
>> plugin means we can't vote on the final jars since it  
>> automatically publishes to the final repository.
>
> Thanks for the info Dain.
>
> Not sure what you mean by "inner spec"

Dependencies between two specs.  For example, connector depends on  
transaction.

> and I should read up on "scope provided".

Provided basically turns of transitive dependencies for those using  
the module.  This is very important for specs like connector since  
that same connector version is used by both j2ee 1.4 and jee 5, which  
would mean a dependency clash over JTA 1.0.1B in j2ee 1.4 and 1.1 in  
jee5.  With provided the spec uses what ever version is provided by  
the environment.

> What happens to the parent pom and the parent pom version during  
> the release of a spec?

The parent pom version is not used by the child pom so there is no  
parent pom version problems during release.  An example of the  
latter, is the generic apache pom which some projects extend from.   
This pom contains general apache information like the locations of  
the apache repositories:

   http://repo.mergere.com/maven2/org/apache/apache/3/apache-3.pom



-dain

Re: Proposed version/spec release process

Posted by Kevan Miller <ke...@gmail.com>.
On Dec 12, 2006, at 3:52 PM, Dain Sundstrom wrote:

> Kevan asked me to go over the development/release process used when  
> we have a single version number.
>
> 1 Make a development module in specs/trunk
>   [Maintince] svn cp specs/tags/<artifactId>-<latestVersion> specs/ 
> trunk/<artifactId>
>   [New] make a new mvn module at specs/trunk/<artifactId>
>
> 2 Make changes
>   There is no need to update inner spec depenencies since all will  
> be marked as scope provided in the pom, so we don't get transitive  
> problems.
>
> 3 Vote and Release
>   update pom version
>   create jars
>   vote
>   publish
>   svn mv specs/trunk/<artifactId> specs/tags/<artifactId>-<version>
>
> Alternatively, we can use the release plugin but the release plugin  
> means we can't vote on the final jars since it automatically  
> publishes to the final repository.

Thanks for the info Dain.

Not sure what you mean by "inner spec" and I should read up on "scope  
provided". What happens to the parent pom and the parent pom version  
during the release of a spec?

--kevan