|
I've added the below to the discussion at... http://jira.codehaus.org/browse/MNG-3092 ...but include here in case anyone else has some ideas. If you consider semantic versioning http://semver.org/ where by using carefully chosen version numbers (enforced by an api analysis tool) and version ranges to specify your dependencies between your components then version ranges need to support some basic ideas. I have component A [1.0.0] and component B [1.1.0] and component A depends on component B with version range [1.0.0,1.2.0) A [1.0.0] depends on B [1.0.0,1.2.0) We start additional development on B so it will initially be B [1.1.1-SNAPSHOT] So A will pull this in as it's current dependency i.e. B [1.1.1-SNAPSHOT] as a dependency (the current behaviour of maven 3.0.3) Work continues on B and someone adds a method to an interface which is used by A, component B's version is increased to [1.2.0-SNAPSHOT] to signal the possible incompatible change since version B [1.1.0] If you think about it, this snapshot of B could be incompatible to A so we need to exclude it in our version range i.e. we modify component A's dependency version range on B to exclude the 1.2.0-SNAPSHOT A [1.0.0] depends on B [1.0.0,1.2.0-SNAPSHOT) So already I'm not liking this since I have to specify I don't want the 1.2 SNAPSHOT but I can live with it. However the dependency pulled in for A will now always be B [1.1.1-SNAPSHOT], there will never be a
release of B[1.1.1] made by us, our
baseline is B[1.1.0] and we have not
made a new baseline release yet for component B but it will at
best be [1.2.0] or a later version. I've concluded but I could be wrong that you need to be able to say whether you want to include or exclude SNAPSHOT in your version ranges. We develop OSGi bundles. Using the PDE analysis API tooling we compare on going development of bundles with a baseline release and update the POM/Bundle-Manifest version as appropriate depending on code changes. So we require to use version ranges with snapshots included when doing continuous integration but do not include SNAPSHOT when doing releases. I actually would prefer A [1.0.0] depends on B [1.0.0,1.2.0) to actually mean... "A depends on B from 1.0.0 up to but NOT including 1.2.0 or 1.2.0-SNAPSHOT" From our point of view, if you do not want 1.2.0 since it will be incompatible then you do not want 1.2.0-SNAPSHOT either since it will also be incompatible. To be clear B [1.1.1-SNAPHOT] is valid in the range above by default. However when building a release we would like to set a property or something equivalent (not in the POM, you do not want to have to go through all the POMS) and exclude SNAPSHOT in version ranges. I suspect other people may require other scenarios so I see
some form of pluggable version range strategy being the answer.
You plugin the functionality you require. The default behaviour
will be what I have outlined My 10 pence --
Paul French Kirona Solutions Ltd Tel: 07803 122 058 E-Mail: [email protected] Web: www.kirona.com
This email and any attachments are confidential and should only
be read by those to whom they are addressed. If you are not the
intended recipient, please contact us on 01625 585511, delete
the email (including any attachment) from your computer and
destroy any copies. Any distribution or copying without our
prior permission is prohibited.
Internet communications are not always secure and may be subject
to delays, non-delivery and unauthorised alterations. Therefore,
information expressed in this message is not given or endorsed
by Kirona Solutions Limited ("Kirona") unless otherwise notified
by our duly authorised representative independent of this
message. No warranty is given that this email (including any
attachment) is virus free. Any views or opinions presented are
solely those of the author and do not necessarily represent
those of Kirona.
|
- maven 3 version ranges with snapshots Paul French
- Re: maven 3 version ranges with snapshots Ron Wheeler
