Re: Version ranges not working

[Jesse Long <jp...@unknown.za.net>]

On 29/09/2012 05:29, Hervé BOUTEMY wrote:
> Le vendredi 28 septembre 2012 09:52:50 Jesse Long a écrit :
>> My point is really about exclusive upper bounds.
> ok, now I'm starting to see the precise idea and believe it can avoid breaking
> subtle logic
> [1.7,1.8) could exclude anything "starting with" 1.8: betas, alphas, alphas-
> alphas, snapshots (but this one is a consequence of excluding alphas since
> alpha < snapshot)
> it's still a mathematical range, just the meaning of the upper bound is
> different and intended as more natural

Works for me.

> Changing this behaviour would need good documentation and communication, but
> seems feasible without wrecking havoc
>
> You'll need to create a Jira issue, perhaps have a vote on the list to check
> that nobody finds big issues with this change (or see the benefit of breaking
> past-compatibility)

I have created a ticket - http://jira.codehaus.org/browse/MNG-5353

>> I expect that [1.7,1.8] should contains 1.7.0 and above (no snapshots
>> and prerelease for 1.7.0) and 1.8.* release versions.
> ouch, 1.8.* release versions in [1.7,1.8]?
> Service packs (1.8-sp1), why not, even if not immediately natural
> but 1.8.1, no, sorry :)
>
>> Having said that,
>> I dont really care too much about this use case and have not thought
>> much about it. I have thought about exclusive upper bounds, and I think
>> my proposal is the best solution.
>>
>> [1.7,1.8-beta): Like I said, there is no sense in that at all. Why would
>> a developer want to include 1.8-alpha, but not 1.8-beta? Indeed, why
>> would he want 1.8.0-alpha4 and not 1.8.0? I think we should not make the
>> majority of use cases, where the exclusive upper bound defines a
>> compatibility break according to semver, to suffer because some users
>> will do weird things like [1.7,1.8-beta).
>>
>> [1.7,1.8-beta) is a valid input however, so we should make a plan for
>> it.
> +1
>
>> We could just say that if the upper bound has a qualifier, compare
>> as per usual. If the exclusive upper bound has no qualifier, then ignore
>> the qualifier of the version being compared to the upper bound. So, in
>> [1.7.0,1.8.0), 1.8.0 is outside the range and so is 1.8.0-alpha1. In
>> [1.7.0,1.8.0-beta) 1.8.0 is outside the range, 1.8.0-beta3 is outside
>> the range and 1.8.0-alpha4 is inside the range.
> I don't think we need special handling: with "exclude anything starting with"
> semantics and the version comparison algorithm, IMHO, we have the rule that
> can be applied to any form of upper bound and stays completely logic and
> previsible
> The more I dig into this semantic, the more I like it :)
Simplicity is good. I think "starts with" is nice and simple.
> A new question: what about exclusive lower bound? would this semantic apply
> too? (I'm tired for the moment, just throwing the question without having
> really thought about consequences)
Dont know, not really worried about it.

Thanks for taking my request seriously.

Cheers,
Jesse

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Version ranges not working

[Paul French <pa...@kirona.com>]

It is clear version ranges are used by some people and they do find them 
useful including me. You cannot predict how and in what circumstances 
specific features of maven will be used by the many people out there, 
good or bad in your opinion.

I still would prefer making version range calculations pluggable where a 
default is supplied (the current). I can then create my own plugin which 
overrides the default and specify it my POM. For example I would 
probably use semantic versioning on artifacts in specific groups which I 
specify and use specific versions for others. Who knows? The fact of the 
matter is I can do what I like and the build will be repeatable (in 
terms of the version range calculation).

Currently when we release an artifact or product we have created a 
release plugin which creates an effective POM listing all versions used, 
including the transistive ones. Hence our release builds are repeatable. 
We can go back in time, branch and fix.

The biggest pain we have is the speed of the dependency calculation when 
developing. I'm sure this can be optimized.


On 01/10/2012 07:22, Hervé BOUTEMY wrote:
> Le lundi 1 octobre 2012 02:31:44 Jesse Long a écrit :
>> I have created a ticket - http://jira.codehaus.org/browse/MNG-5353
> thank you
> I changed it from "Bug" to "Wish": no, nobody ever asked for such a behaviour,
> it's really a new idea AFAIK
> which BTW seems a good enhancement IMHO
>
> now we need to check with people using ranges that it is ok for them: if
> anybody can think of a problem, please share
>
> Regards,
>
> Hervé
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Version ranges not working

[Hervé BOUTEMY <he...@free.fr>]

Le lundi 1 octobre 2012 02:31:44 Jesse Long a écrit :
> I have created a ticket - http://jira.codehaus.org/browse/MNG-5353
thank you
I changed it from "Bug" to "Wish": no, nobody ever asked for such a behaviour, 
it's really a new idea AFAIK
which BTW seems a good enhancement IMHO

now we need to check with people using ranges that it is ok for them: if 
anybody can think of a problem, please share

Regards,

Hervé

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org