On 9/20/06, diroussel <[EMAIL PROTECTED]> wrote:
This, and the previous fop thread, has made me think about what happens with
versioning and simple fixes.
For example
A-1.5 depends on B-1.0
B-1.0 depends on C-2.0
Now there is an API compatible fix in C, and the version is changed to
C-2.0.1. Now for A to get the bennifit of this change both A and B need to
be changed. It's a bit of a pain, but we get immutable versions and thus
can reproduce builds easily.
Now, I'm not a .NET expect, so correct me if I'm wrong. But according to
the CLR book [1] one of the ways the CLR is better than the java JVM is the
handling of versions and version meta-data. One thing you can do with this
version meta-data is to map versions. So you can say that "any module that
depends on C-2.0 should use C-2.0.1 instead". So if this meta data is in
place when you build A then C-2.0.1 will be used, and B doesn't have to be
version bumped.
When you build A you don't know anything about C-2.0.1 because it does
not exist.
Versions in repository explicitly define what versions the have been
released against or tested with. If I release A 2.0 depending in C 2.0
and then I want to say i'm compatible with C 2.0.1 I have to update
myself releasing A 2.0.1, because people using A 2.0 may not be
compatible with C 2.0.1 and don't want automatic change of version
So if one can add this version meta-data to A's pom, or in the settings.xml
one can map versions in a controlled way, keeping reproducability, but
avoiding the pain of version bumping all poms in a dependancy chain.
Does that make sense? Do people think a similar mechanism in maven would be
useful?
David
[1] "Essential .NET", Don Box et al,
http://www.amazon.co.uk/Essential-Net-1-Don-Box/dp/0201734117
Carlos Sanchez-4 wrote:
>
> To make clear to all maven users, this is the current repository policy:
>
> We don't allow pom changes that can alter reproducibility, which means
> DEPENDENCIES IN POMS WILL NOT BE CHANGED.
>
> The repo is only a way to distribute other people work. We don't
> repackage their work, only exceptions are for distribution of sources
> or javadocs when the original project don't provide them.
>
> You CAN NOT PROVIDE YOUR OWN BUILT VERSION OF ANOTHER PROJECT.
> As an example if fop adds anything to he manifest that you don't like
> or think is wrong it's not our problem, ask them if they want to
> change.
>
> You can always as for an upload of anything you want to a group under
> your project/domain name, as long as the license allows it.
> Eg. I want to provide my own version of fop, created by my project
> hosted in foobar.org. I can request an upload under org.foobar group.
> I can upload to org.foobar anything I want as long as it follows the
> maven conventions.
>
> In case a pom is clearly bad, broken or unmanageable, a new pom can be
> uploaded for users convenience, under same version appending -1. The
> pom description must clearly state it's just for maven users
> convenience and the originating project must be asked to provide the
> pom improvements in next version (in case they provided the bad one)
> Eg. http://repo1.maven.org/maven2/groovy/groovy/1.0-jsr-05-1/
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
> -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Repository-Policy-tf2306302.html#a6413289
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
