Version ranges (was Re: How do I go about contributing a plugin to mojo?)

[Ralph Goers <Ra...@dslextreme.com>]

Jason van Zyl wrote:
>
> On 17-Jul-08, at 8:08 PM, Ralph Goers wrote:
>
>>
>>
>> Michael McCallum wrote:
>>> why not just specify the dependencies with version ranges, if you do 
>>> there is no need to rewrite anything it just works...
>>>
>>>
>> My builds never use version ranges.  We require that builds be 
>> reproduceable at any time in the future. Version ranges don't 
>> guarantee that.
>
> Version ranges by themselves don't guarantee anything, but I think 
> what you're saying is that they don't guarantee a released versions 
> artifacts being reproducible.
>
> The way OSGi works is that the ranges play a part at build time and 
> runtime. During the time working up to a release ranges are useful to 
> allow flexibility of testing new versions of code, much like the way 
> snapshots work and at the time of release you can choose to lock the 
> versions down. If you lock the versions down then there is no 
> flexibility in the runtime to accept new versions. Oleg and I have 
> been trying to work out a way where we can have our cake and eat it 
> too: allow the flexibility of variable runtime versioning while 
> keeping an exact list of what actually worked for a release. I think 
> anyone who has been doing this for a while realizes that once a 
> project has been QA'd it makes no sense to allow everything to vary. I 
> think it's a hybrid of these approaches that will allow the most 
> utility across build and deployment.
>
That pretty much sums up what I am saying. I view an OSGi bundle a 
little differently than a maven project build primarily because the 
bundle presumably has a larger granularity.  In both cases though, I 
would want a version upgrade to be deliberately controlled. Even while 
in development we don't use version ranges. If we choose to upgrade the 
version of an artifact we do it in our third party pom's 
dependencyManagement and then retest. With OSGi I'd imagine doing more 
or less the same thing by installing the new bundle and testing long 
before QA.  However, this would be done deliberately, not automagically.

Ralph

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

Re: Version ranges (was Re: How do I go about contributing a plugin to mojo?)

[Jason van Zyl <ja...@maven.org>]

On 18-Jul-08, at 10:30 AM, Ralph Goers wrote:

> Jason van Zyl wrote:
>>
>> On 17-Jul-08, at 8:08 PM, Ralph Goers wrote:
>>
>>>
>>>
>>> Michael McCallum wrote:
>>>> why not just specify the dependencies with version ranges, if you  
>>>> do there is no need to rewrite anything it just works...
>>>>
>>>>
>>> My builds never use version ranges.  We require that builds be  
>>> reproduceable at any time in the future. Version ranges don't  
>>> guarantee that.
>>
>> Version ranges by themselves don't guarantee anything, but I think  
>> what you're saying is that they don't guarantee a released versions  
>> artifacts being reproducible.
>>
>> The way OSGi works is that the ranges play a part at build time and  
>> runtime. During the time working up to a release ranges are useful  
>> to allow flexibility of testing new versions of code, much like the  
>> way snapshots work and at the time of release you can choose to  
>> lock the versions down. If you lock the versions down then there is  
>> no flexibility in the runtime to accept new versions. Oleg and I  
>> have been trying to work out a way where we can have our cake and  
>> eat it too: allow the flexibility of variable runtime versioning  
>> while keeping an exact list of what actually worked for a release.  
>> I think anyone who has been doing this for a while realizes that  
>> once a project has been QA'd it makes no sense to allow everything  
>> to vary. I think it's a hybrid of these approaches that will allow  
>> the most utility across build and deployment.
>>
> That pretty much sums up what I am saying. I view an OSGi bundle a  
> little differently than a maven project build primarily because the  
> bundle presumably has a larger granularity.

In can, and a lot of people I've seen use OSGi use ranges.

>  In both cases though, I would want a version upgrade to be  
> deliberately controlled. Even while in development we don't use  
> version ranges. If we choose to upgrade the version of an artifact  
> we do it in our third party pom's dependencyManagement and then  
> retest. With OSGi I'd imagine doing more or less the same thing by  
> installing the new bundle and testing long before QA.  However, this  
> would be done deliberately, not automagically.

Sure, this is sane for your 3rd party deps, but I think you have to be  
a little more dynamic while integrating team code. You just need to be  
able to track the point at which it was stable and lock it all down.  
Vary freely while in determination mode, when successful make that  
deterministically reproducible.

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

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

What matters is not ideas, but the people who have them. Good people  
can fix bad ideas, but good ideas can't save bad people.

  -- Paul Graham


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