incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Spicar <daniel.spi...@trialox.org>
Subject Re: releasing individual modules (WAS: Can someone create 0.3-incubating version in our JIRA project?)
Date Mon, 26 Mar 2012 09:21:53 GMT
On 24 March 2012 15:57, Reto Bachmann-Gmür <reto@apache.org> wrote:

> On Mon, Mar 19, 2012 at 2:54 PM, Fabian Christ <
> christ.fabian@googlemail.com
> > wrote:
>
> > Hi,
> >
> > Am 19. März 2012 14:36 schrieb Daniel Spicar <dspicar@apache.org>:
> > > But how do you handle maven version numbers? In order for this to make
> > > sense I think you handle versions manually per module. That means
> after a
> > > release you do not make the module depend on the latest SNAPSHOT
> versions
> > > of all its dependencies but rather you stick with the oldest release
> >
> I tink you mean newest release
>
> I mean the the "first" release it needs to depend on. Not the newest
release out. E.g. If a API consumer bundle depends on version 1.1.1 of the
API, it should always depend on 1.1.1 as long as it doesn't need to depend
on a newer version. No matter if meanwhile version 1.2.5 of the API is out.


> > > version you depended on and only increment to the next SNAPSHOT when
> you
> > > require new features or some other reason may require an update (e.g.
> > major
> > > version change).
> >
> > I think this is the way to go. Currently, we have the same issue in
> > Stanbol and I am thinking about doing it exactly this way.
> >
>

Why not release a fresh parent whenever a set of modules is released? All

 modules in trunk should then be updated to use the new parent. The effect

is the same: a module depends only on relased components unless there is
> reason to depend on snapshot in which case the modules will be released
> together. I think the maven versions plugin comes in very handy here.
>

Given which release process? In the current release process the parent has
lots of SNAPSHOT versions in its dependency management because all bundles
are automatically snapshotized after a release. So in order to be
consistent you can either revert the versions of unchanged/unreleased
bundles in dep. management to the last release version when you release a
new parent, and put it back to the latest snapshot version after release
(plus update each module's pom to depend on the latest parent), or you have
to release all bundles and snapshotize them again, causing a version jump
even without changes. But it seems unnecessary to have to meddle with poms
of bundles that did not change simply because an the implementation in an
independent bundle changed.

Best,
Daniel

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