Release candidates would go into the release repository. But I think generally people should be able to get by just installing from source themselves, if they need to test a release candidate...
-Stephen On 9/8/07, Brian Moseley <[EMAIL PROTECTED]> wrote: > > On 9/8/07, Stephen Duncan <[EMAIL PROTECTED]> wrote: > > Hey now, that's a problem... 0.3.0 hasn't been released, but now > anybody > > using that repo might download a 0.3.0 pre-release as if it's the final > > release; and if they don't explicitly delete it from their local > repository, > > and if we were to deploy new 0.3.0 jars over-the-top of the ones you > > deployed (which is normally never allowed for the real central > repository), > > they wouldn't get the new jars. Please stick to deploying either > SNAPSHOTs > > to the snapshot repository, or, if trunk & the 0.3.0 branch aren't the > same > > anymore, then just stick to installing into your local repository. > > > > I guess typically this would be solved by updating the version number so > > that what would have been 0.3.0 final will be something like 0.3.0-1 or > > something like that... I imagine that's an unattractive option to those > > focused on the Ant build... Any ideas on how to decide if there are any > > user's who are going to be bitten by this, and if so, how to solve it? > > you're right. the ant folks can afford to be sloppier about version > numbering. the dual build process thing is such a headache. that and > my noobness with deployment... > > in the future, once we make a release branch, we can use the 0.x.y-rcz > convention. in fact, i could do that now, redeploy the jars with those > names, and remove the erroneous ones. although, is it still correct > according to maven policies to put those jars into the snapshot > repository, or should they go into the release repository? > -- Stephen Duncan Jr www.stephenduncanjr.com
