incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Spicar <daniel.spi...@gmail.com>
Subject Re: releasing individual modules and versionig
Date Thu, 21 Feb 2013 18:55:43 GMT
2013/2/21 Reto Bachmann-Gmür <reto@apache.org>

> Hi Daniel
>
> I'm not arguing for a centralized dependency management. so be both agree
> there. My question is how to best move the dependency versions from the
> dependency management to the projects.
>
> The mvn versions plugin doesn't seem to support this.
>
> But there is an issue with this approach as well. Often you will want to
> > use the new features of a module A from some other module B. So you need
> to
> > go to B's pom and adapt the version number of its dependency. Maybe you
> > need to do this with several other modules as well. But you don't do this
> > with all modules (e.g. Stable Module C has no changes and does not
> require
> > any new feature).
>
> No. I suggest you do this for all modules in trunk which is easily done by
> executing the following:
>
> mvn versions:use-latest-versions -Dincludes="org.apache.clerezza"
> -DallowSnapshots=true -DexcludeReactor=false
>
> If C is mantianes it should be adapted to use the new version of A. If C is
> not mantained it should be moved out of trunk.
>

And this is, what should be avoided in my opinion if possible. What you
describe means a new version of C needs to be released. This is an
unnecessary release of C. C contains no changes. Only it's metadata is
changed and in this case not even that is necessary because (given that the
change in A does not break the old API), the new version of A satisfies C's
requirements at runtime. You only need to make sure OSGi is able to resolve
it correctly.

But you are right. Back when I investigated this there was no support for
this workflow in the mvn release plugin. Nevertheless it strikes me wrong
to have to change version numbers of modules that contain no changes.


>
> Cheers,
> Reto
>


Daniel

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message