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}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
