Mailing-List: contact clerezza-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: clerezza-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CALvhUEVRj_CM5s8rnPDw=R+F7ENSFOjJ+X1GTds7JwxVcvLpSQ@mail.gmail.com>
References: 
 <CAKJT5WQDSaAR2L0FimhQg31k2CKYwAME5LGEfCFCoBK1rWbJwA@mail.gmail.com>
	<CALvhUEWiA0N2f4nELxDzU7o1U2KR91pQANzWcdZ7JxRBmK7V5g@mail.gmail.com>
	<CAKJT5WRBMFo31bUgOri7NhOzcr0CAYFyk_Zpqi8kQF41Uh5Dog@mail.gmail.com>
	<4F611F62.5000705@4sengines.com>
	<CA+_sZ+gkMk-DnpZh4N+PhdT2f3SGL4u2m2+dg1SOwFEXufcy8A@mail.gmail.com>
	<CAKJT5WSKtC1ad17qQQK5UjP_oC3H=eBci879q5Yz7KDugdV50g@mail.gmail.com>
	<CAEWfVJnoXpaxJ4-DhgpcZnarS4mGzpSA3B_k9ccQUXFt631r4g@mail.gmail.com>
	<CAKJT5WR94nJ4caFp4=JcE-=N-XyygN1twGL+Ck3zY_81fsim-g@mail.gmail.com>
	<CA+_sZ+gb3rSYikrE8G3apmdLqHn=hSWENWiNrn7jOCUGUbkSYQ@mail.gmail.com>
	<CALvhUEU5ov_=uibGGQcka+OmM0nnh2qvP-FLZ8xirSCy6XS1UA@mail.gmail.com>
	<CAKJT5WRkuugU05Na46mR7cP5a4fFQK1=ExOQJJMP-LM4KgOa_w@mail.gmail.com>
	<CALvhUEVRj_CM5s8rnPDw=R+F7ENSFOjJ+X1GTds7JwxVcvLpSQ@mail.gmail.com>
Date: Mon, 26 Mar 2012 14:53:16 +0200
Message-ID: 
 <CAKJT5WRL3jM=TbS2b9PPY-ciDFtm+PzkEaHYhE0Fd7TVhOTjvw@mail.gmail.com>
Subject: Re: releasing individual modules (WAS: Can someone create
 0.3-incubating version in our JIRA project?)
From: Daniel Spicar <daniel.spicar@trialox.org>
To: clerezza-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=485b393aaadfa5ebbf04bc24db99

--485b393aaadfa5ebbf04bc24db99
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 26 March 2012 13:44, Reto Bachmann-Gm=FCr <me@farewellutopia.com> wrote:

> 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=FCr <reto@apache.org> wrote:
> >
> > > On Mon, Mar 19, 2012 at 2:54 PM, Fabian Christ <
> > > christ.fabian@googlemail.com
> > > > wrote:
> > >
> > > > Hi,
> > > >
> > > > Am 19. M=E4rz 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.
>

Given the process I outlined the idea was that you don't need to care about
looking for specific versions. This situation will evolve naturally because
you do not touch bundles that you don't need to worry about. However the
effort will be on the developer to apply OSGi semantic versioning
correctly. Then, if you overlook something, you will see it at runtime
because dependencies can not be resolved. But this would be problematic
when OSGi versioning is not used.

And the latest documentation would be available because the launcher
project would use the latest versions. At runtime, the "old" dependency
would only influence the declared version requirement, not the
implementation. But it would allow the bundle to run with older
requirements too.


> >
> >
> > > > > 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? A=
ll
> >
> >  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 i=
s
> > > reason to depend on snapshot in which case the modules will be releas=
ed
> > > 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 buil=
d
> 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.
>

Well currently, in trunk, everything (or at least almost) is a snapshot
version. So next time someone tries to release just one module the problem
appears and the situation won't change if the released module is
snapshotized after release (because still the same amount of modules will
all be snapshot versions). The problem lies in central dependency
management creating unneeded "dependencies" between everything managed in
dependency management. These dependencies don't apply at runtime
(especially because we do not use OSGi versioning) but affect the source
release of the module.

>
>
> > 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 releas=
e
> > (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 ju=
mp
> > 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 o=
ld
> 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
>

You mean, that if I want to release a new version of (e.g.) the user
manager. I would make it depend on parent 0.2 (when it is currently on
0.3-SNAPSHOT in trunk)? Then the source release will be really awkward
because dependency management of parent 0.2 says that user management
version is 0.2 (I think) but you just released the code base of 0.3 (I
think). If something depends on user manager and it needs the new version
it needs to declare it manually. Then you dilute the whole idea of central
dependency management. The same for projects that use clerezza, they would
need to analyze what we changed and add manual dependency declaration if
they want to use the new release of user manager because from dependency
management they inherit version 0.2. The alternative is to release a new
parent with new dependency management and revert all unrelated modules to
the latest release (I think you suggested that too).

Before I was under the impression that currently we do it differently and
we do not allow dependencies on old parents. Nevertheless you will not get
rid of manually making sure that dependencies add up in any of those cases.

But in general this is part of the process I suggested. Unrelated bundles
should be able to depend on the version they need, not be forced to depend
on the latest version even when nothing changed for that bundle. Some of
the additional specifics arise from the introduction of OSGi package
versioning and its semantics.

Best,
Daniel

--485b393aaadfa5ebbf04bc24db99--