incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmür ...@farewellutopia.com>
Subject Re: releasing individual modules (WAS: Can someone create 0.3-incubating version in our JIRA project?)
Date Mon, 26 Mar 2012 11:44:06 GMT
On Mon, Mar 26, 2012 at 11:21 AM, Daniel Spicar
<daniel.spicar@trialox.org>wrote:

> 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.
>

For bundles, i.e in the OSGi environment you're right in principle. In
practice however I think that the effort to check which is the oldest
version that suffices and ensure this with tests might often be a too big
effort.

For maven artifacts I would default to the newest release, pure api
artifacts are seldom and even there the newer version might bring
advantages, such as a better documentation.

>
>
> > > > 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?

No, moving the parent project in a subdirectory and having a reactor build
pom where currently the paren pom is.


> 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.

I think that only modules that are part of the release are snapshotized.


> 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.
>

A module that isn't part of the release isn't touched. It might have an old
snapshot parent as parent. When only a single project is to be released
then it is enough to update the parent to the latests released version. If
multiple modules have to be changed and released then you must manually
make sure that the parent has snapshot versions of the artifacts to be
relased while the other dependencies in dependency-management  have to
point to the latest release, this is best done in an svn branch.

Cheers,
Reto

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