geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Can we conclude the Vote on WS-META-Data early? --- Please resond if you object
Date Thu, 14 Jun 2007 21:08:38 GMT

On Jun 14, 2007, at 11:44 AM, Matt Hogstrom wrote:

> On Jun 14, 2007, at 2:22 PM, David Jencks wrote:
>> I don't understand the release process for specs to tell what is  
>> going on, however there is no 
>> geronimo/specs/tags/geronimo-ws-metadata_2.0_spec-1.1.1 (what i'd  
>> expect a 1.1.1 to be under) nor a 
>> geronimo/specs/tags/geronimo-ws-metadata_2.0_spec-1.1 (what is  
>> actually shown in the newly added scm info).  IMO its slightly  
>> better to have no information rather than wrong information.
> Fair comment I think.  For the most part few people actually follow  
> through to actually release software and we've done a poor job of  
> releasing them.  IIRC Dain had indicated he would handle the specs  
> but in reality it needs to be a community responsibility and not  
> dependent on one person.  So, as far as that goes, I believe we do  
> something different in Specs than we do for the Geronimo server and  
> I'm unaware of any documentation except perhaps older e-mail  
> threads.  If there is some doc a link would be appreciated.  If  
> there is blame to be assigned here then I spect it would be on me  
> and not Prasad as he asked my opinion on how to do some of this.   
> So with that, here is my input.
> Following what we do in Geronimo (where we do not use the release  
> plugin for a whole raft of other reasons) the branch has been  
> updated to look like it will exist when it is svn mv'd to https:// 
> so with that in mind  
> I think the SCM information is correct (or will be when the vote  
> concludes and the various bits are moved to their respective  
> locations.)  I think the SCM information is nice to have.
>> At this point I'm
>> +0 on releasing the original (no scm info) ws-metadata 1.1.1 jar
>> -0 on releasing the modified one.
>> Keeping track of the spec release procedure is beyond my limited  
>> abilities, but what is happening is not what I expected.  My dim  
>> recollections of the release procedure was that we would use the  
>> maven release plugin and that would correctly tag the source and  
>> generate/modify all the artifacts consistent with the new tag.   
>> I'm confused because there is no 1.1.1 tag that I can find for ws  
>> metadata and the scm info does not appear to be getting updated.   
>> Is this a maven bug, is it not supposed to be updated by the  
>> release plugin, or something else?
> It is not your inability to consume them I think it is our lack of  
> initiative to document and follow them.  Since I've been release  
> dog for a while I'll go hack up the CWiki and try to get this done  
> once and for all.  However, I'll do that on another thread.
> Regarding the scm tags, as I noted above, it was a manual  
> compromise as I rememer in the past people complaining that they  
> wanted to vote on binaries that were not being released rather than  
> what the release plugin might generate.  Perhaps my inability to  
> recollect is contributing to this already confusing and wearing  
> discussion on release shtuffes.

I found this email from dain which is the last documentation on spec  
releases I can find, from dec 12 2006:

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/ 
   [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  

3 Vote and Release
   update pom version
   create jars
   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  


I'm pretty sure the release plugin can now push the artifacts to a  
staging area , and then later actually move them to the appropriate  
repo.  I think it would be a good idea to investigate this and I  
might even be willing to do that myself.

david jencks

View raw message