geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: publishing snapshots
Date Mon, 04 Dec 2006 22:11:26 GMT
On Dec 4, 2006, at 1:57 PM, Paul McMahan wrote:
> Yes they are new specs.  I used 1.1-SNAPSHOT because the spec I was
> using as a template (geronimo-servlet_2.5_spec) started with that
> version number.  Wish I had poked around a little more and I would
> have realized.

No worries... not picking on you, just happened to notice this in  
your change.

>> Really, if we are going to version these modules separately, then
>> they should start at 1.0-SNAPSHOT.  If we version the entire project
>> together, then its obviously fine to add new modules when the version
>> is not 1.0*
>> But until we collectively see that light... :-P... lets use
>> consistent and logical versioning for these modules.  Skipping
>> versions is just going to confuse people.
> I agree but unfortunately I have already published to the snapshot
> repo using 1.1-SNAPSHOT.  Should I address your concern by manually
> deleting them from the repo and republishing them as 1.0-SNAPSHOT?  Or
> would that be overkill?  I'm fine either way.
> BTW, there are some other specs in there that also did not start at
> 1.0-SNAPSHOT (at least not published in this repo):
> -  geronimo-corba_3.0_spec
> -  geronimo-servlet_2.5_spec
> -  geronimo-spec-corba
> -  geronimo-ws-metadata_2.0_spec
> Maybe its too late for those(?)

Well, this is going to be an ongoing problem with using per-module  
versions for these.

Seem fairly obvious to me if you are creating a new module, copied  
from another or not, that you should always change the version, name,  
artifactId of the module.

Anyways... if these were only published as snaps, then I would remove  
the artifacts from the m2-snapshot-repository, update the poms with  
1.0-SNAPSHOT, update deps, and then redeploy.

  * * *

I still recommend using one version for all specs though... then all  
this version muck basically goes away.  This may be more and more  
important as I get more stuff automated, as its not really easy to  
ensure that code put into specs will actually be used by a dependency  
project.  So its hard to say if specs/trunk is compatible with server/ 
trunk with any degree of certainty... I would normally expect that  
they would be compatible... but Maven's remote repo/dependency muck  
(plague in disguise) really does more to promote build instability  
than to allow codeline consistency.


View raw message