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