might be better off using the version ranges notation for this kind of thing, I don't think you want to get into the habit of x.y being some kinda fuzzy defintion, it should refer to a specific version.
[3.7,) or something along those lines... http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution then when it comes to your release time, pin it down to a specific version of the pom for release jesse On 7/5/06, Mark Hobson <[EMAIL PROTECTED]> wrote:
On 05/07/06, Steve Loughran <[EMAIL PROTECTED]> wrote: > OK, but the other part of the problem is pushing the changes out to the > user. > > in a linux distro, what you are effectively buying is a set of artifacts > compiled on the same gcc version/options, and a subscription that keeps > your box up to date. They are usually manual or cron updates. > > If you're using an artifact 3.7, and the pom goes to 3.7-1, you need to > get that new pom, without having your stuff updated. Except when you > dont, of course, because you've just QA'd everything against a previous > version and dont want stuff with new metadata creeping in. Could we not use the syntax 3.7 to represent 'the latest revision of 3.7', whereas 3.7-1 would lock the version down to 3.7 rev 1? So during development people could use 3.7 to allow updated revisions of the pom to be pushed to them, and then for reproducable builds they could use the 3.7-1 syntax. The release plugin could fully-qualify any version numbers of the form 3.7 to the currently-used revision, e.g. 3.7-1, at release time. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- jesse mcconnell jesseDOTmcconnellATgmailDOTcom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
