[
http://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=266659#action_266659
]
Paul French commented on MNG-3092:
----------------------------------
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 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 verion 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 componment 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 baselien release yet for component B
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 CI 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 outlines :)
My 10 pence
> Version ranges with non-snapshot bounds can contain snapshot versions
> ---------------------------------------------------------------------
>
> Key: MNG-3092
> URL: http://jira.codehaus.org/browse/MNG-3092
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
> Reporter: Mark Hobson
> Attachments: MNG-3092.patch
>
>
> Contrary to the 2.0 design docs:
> "Resolution of dependency ranges should not resolve to a snapshot
> (development version) unless it is included as an explicit boundary."
> -- from
> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification
> The following is equates to true:
> VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new
> DefaultArtifactVersion( "1.1-SNAPSHOT" ) )
> The attached patch only allows snapshot versions to be contained in a range
> if they are equal to one of the boundaries. Note that this is a strict
> equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
