geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository
Date Mon, 04 Apr 2005 21:48:39 GMT
On Mon, Apr 04, 2005 at 03:10:55PM -0400, Geir Magnusson Jr wrote:
> On Apr 4, 2005, at 2:20 PM, Dain Sundstrom wrote:
> >On Apr 4, 2005, at 9:59 AM, David Blevins wrote:
> >
> >>Seems like we are going in circles on this one.  Can we reasonable 
> >>agree that it isn't practical to hold up a Geronimo release till 
> >>every project we have a snapshot depenency on is able to hand us some 
> >>sort of official release of their own?
> >
> >+1
> >
> >We do our best to eliminate the SNAPSHOTs, but the reality is we can't 
> >always eliminate all of them.
> You guys are crazy.  We have to be able to eliminate them, especially 
> for production releases. Even before we're 1.0, I would expect that our 
> 0.8 and 0.9 stuff are becoming good enough for some dependable use, and 
> thus we should only depend on released software.

You do realize we are talking about two different things here.  No one in their right mind
would propose SNAPSHOT dependencies are a good idea for releases of any kind.  Not only do
I strongly agree, I think we shouldn't switch something back to SNAPSHOT after a release.

Even further, I don't think pressuring projects into giving us an officially named version
of our SNAPSHOT when they aren't ready to release is a solution either.  Then we are just
turning a blind eye and saying, "not my problem."

Our current reality is that we do have over a dozen SNAPSHOT dependencies and we will need
to release soon enough.

I only see two solutions to this releasing issue:

 1. Use date stamped (cvs) or revision stamped (svn) jars in place of SNAPSHOTs on releases.
 2. Not release until we can truly eliminate all SNAPSHOT usage--not just get other projects
to relabel our SNAPSHOTs so we feel warm and fuzzy.

My long term preference is 2, though I'm ok with 1 in the very short term.


View raw message