Can you give a concrete example of a version range that you'd like to use, and explain why you need it?
-- Peter Niederwieser Principal Engineer, Gradleware http://gradleware.com Creator, Spock Framework http://spockframework.org Blog: http://pniederw.wordpress.com Twitter: @pniederw phil.messenger wrote: > > Hi, > > I've got an interesting problem with branches and version ranges. We've > got a fairly typical git based workflow, where we create new branches for > feature development. We use Jenkins to perform CI builds, and have got > this configured to automatically create a new build job when a branch is > created. > > We use Nexus to store dependencies, versioned, for each build. > > A typical project my have a group of "co.globaldawn", and a name like > "classifications-lib". Version numbers are of the format > "1.${buildNumber}-${branchName}", where build number is the number of > builds that have been conducted in that branch. > > So if the "classifications-lib" project is at version 1.333 and is > branched to "feature1234", we end up with an artifact like: > "classifications-lib-1.0-feature1234". The dependency declaration for this > is "co.globaldawn:classifications-lib:1.0-feature1234" > > So far, not too bad... > > We also use version ranges in some of our dependencies. This doesn't work, > because Ivy basically ignores the "-feature1234" part of the version > range. > > So how should I handle version numbers, branches and version ranges? > > Phil. > -- View this message in context: http://gradle.1045684.n5.nabble.com/dependencies-with-branches-tp4659295p4659337.html Sent from the gradle-user mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
