incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmür <r...@apache.org>
Subject Re: releasing individual modules and versionig
Date Fri, 22 Feb 2013 18:16:23 GMT
On Thu, Feb 21, 2013 at 9:03 PM, Daniel Spicar <daniel.spicar@gmail.com>wrote:

> 2013/2/21 Reto Bachmann-Gmür <reto@apache.org>
>
> > On Thu, Feb 21, 2013 at 7:55 PM, Daniel Spicar <daniel.spicar@gmail.com
> > >wrote:
> >
> > > 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.
> >
> >
> > No,  you only release C if added some new features there otherwise you
> just
> > have C 2-SNAPSHOT version in trunk which keeps being updated to depend on
> > the latest versions of the other modules.
>
>
> > If you have a module D that depends on C and you want to release this the
> > you either have to release C as well or have D depend on the released C 1
> > in the release branch (and for depending on the latest release the
> > versions-plugin has support too)..
> >
> >
> Yes this is the same in practice. Dependencies don't care about branches,
> because they are defined in maven. Maven cares about version numbers.
>
> But what happens with D is not so much the question. It's pretty clear.
> Either D needs new features from C or not. If not it can depend on the old
> version. Otherwise the new version of C is required for the new version of
> D and both need to be released.
>
> The question is what happens to C when it depends on B and B is changed
> (the other direction in the dependency graph). Of course you can update C's
> meta data in a SNAPSHOT version. As long as C not released we don't really
> care about it.
>
> But when you want to release a module A (or launcher) with updated B (maybe
> A needs new features from B or non API changing bugfixes have been
> implemented). What do you do with C?
>
You will use the latest relased version of C. Which means that as C is not
part of the release branch the dependency in the launcher pom will be
switched back to the latest released version.

The alternative is you release C as well because you don't want to mix
> version numbers in dependencies. This as quite awkward effects in my
> opinion. Stable modules will go trough various version changes without ever
> changing code, only because their dependencies change.
>
I fully agree.


>
> The whole scheme I came up with is aimed at preventing these unnecessary
> changes in version number. It's not my idea. I compiled it from other
> Apache projects using maven and OSGi that seem to have the hang of this
> (mainly sling [1,2]).
>



>
>
> >
> > >
> > > 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.
> > >
> >
> > But that's like that also with normal usage of the relase plugin, After
> the
> > release you have a SNAPSHOT version in trunk which is identical (apart
> from
> > the version number) to the released version.
> >
>
> Well after battling it out with the release plugin many times already I am
> not so convinced it actually does the right thing. It does not seem to work
> well with modular projects in mind. The scheme I suggest will probably not
> work with the plugin but on the other hand there is no need to actually
> snapshotize every single module after release. I imagine many modules will
> remain stable (and untouched) for quite some time. It would shift the focus
> on releasing singular modules and small groups of collaborating modules at
> a time. How much effort this actually creates I can not tell now. It would
> need to be tested.
>
The Stanbol way is to snapshotize the module but still depend on the
released version in the other modules in trunk. In my experience this is
quite a pain developing. You cannot just build stanbol offline after
deleting org/apache/stanbol in your repo. And when you want to see who
depends on a method in eclipse you first have to update all depent modules
to use the snapshot version. So with my suggestion we might slightly
increase the release burden (but I think not too much, as the mvn version
plugin can roll back to the released version) but simplify development. It
doesn't change anything in terms of nut needing to release modules without
actual changes.


>
>
> >
> > But yes, rather than trying to foresee every possible future it would be
> > good to have some indispiputed things done. Do you see any options to
> move
> > our iternal dependencies out the dependency management without doing this
> > by hand?
> >
>
> I have spend a lot of time in 2011, early 2012 with this question.


I think you misunderstood the question. Its just about how to insert the
dependencie versions in the moduke poms after removing clerezza modules
from dependency management.

Cheers,
Reto

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