cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: Releasing from trunk
Date Thu, 15 Feb 2007 07:04:15 GMT
Simone Gianni wrote:
> Reinhard Poetz wrote:
>> I've been working on the release for the past couple of hours. As it's
>> late here, I need some sleep. Unfortunatly this means that the trunk
>> is broken ATM. I will continue later today and fix all poms.
>> Sorry for any inconveniences.
> Just a quick question. Why don't we use version ranges instead of fixed
> version numbers in our internal pom dependencies?
> While using a version range on an external dependency can be dangerous
> 'cause we are not sure they will respect versioning rules, we could use
> them for internal dependencies and save a lot of work when the version
> of a single component changes and avoid having to cleanup the
> repository, rebuild everything, change the version in the pom, re-clean
> the repository and so on. Also because when we will have "1.0.0" version
> of a block published on public repository it will be a real pain to
> debug which components are still pointing to instead than to the new
> 1.0.1 version.
> Is there some hidden problem with version ranges?

Simone, I have to admit that I don't understand the problem that will be solved 
by version ranges.

Let's assume that you use cocoon-forms-1.0.0.jar which has a dependency on 
cocoon-core-2.2.0.jar. After a while we release cocoon-core-2.2.1.jar. If you 
upgrade your own project descriptor to the new version, Maven will use this 
instead of the version set in cocoon-forms.

What would be different with version ranges?

Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}


View raw message