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 Wed, 20 Feb 2013 17:14:50 GMT
Hi Daniel

I do not really understand your point 3. Why should a module not depend on
the latest released version of the modules it depends on? I would say go
for the newset version in maven and if there is a need for it configure the
bundle plugin to make sure the older version are accepted. But the latter I
would only do if people shout for it. OSGi is considered complex by many
developers so I think we should keep it as easy as possible.

Another thing: Do you know of any easy way to add the version numbers to
the individul poms?

Cheers,
Reto


On Wed, Feb 13, 2013 at 10:53 AM, Daniel Spicar <dspicar@apache.org> wrote:

> Hi Reto,
>
> In general I agree with the approach.
> I have been investigating this issue earlier too. I don't really have time
> to get familiar with the details of this problem again but I remember, that
> the method I suggested pretty much had the following features:
>
> 1. No Centralized Dependency Management in higher level POMs (except for
> general utilities that we *want* all modules to use, e.g. slf4j).
> 2. Modules have to be developed as if they are self-contained (so they
> manage their own dependencies to other modules).
> 3. (Released) modules can only depend on released versions but it is not
> necessary to depend on the latest released version. This point is important
> for not having to touch other modules that have no code changes when
> releasing your module.
>
> More info for point 3: Modules depend on the oldest/lowest version they
> *need*. There is not problem for a module to depend on version 1.0 when we
> are at 1.8 - given the module does not need any of the new features.
> However there should be a minimal version number policy that makes sure we
> handle non-backwards compatible changes correctly because the OSGi
> container will only have the latest version of the module running but it
> needs to satisfy dependencies for older versions as well. When there a re
> non-backwards compatible changes in the new version, this needs to be
> addressed in some manner. There is a whole lot coming into this point if
> you want to use OSGi semantic versioning though. Maybe we can just skip
> that for now. But we need to make sure that the OSGi runtime will run with
> the latest modules (e.g. Version 1.8) but dependencies on older Versions
> (e.g. 1.0) will be satisfied by the 1.8 bundle (this is actually what the
> OSGi semantic versioning is meant for - but it's quite complex because it
> forces the devs to understand the version policy when making changes).
>
> Is that more or less what you meant?
>
> Regards,
> Daniel
>
> 2013/2/12 Tommaso Teofili <tommaso.teofili@gmail.com>
>
> > I see your point, let's go with this approach and if we find anything
> > better in the meantime then we'll switch to that ;)
> >
> > Tommaso
> >
> >
> > 2013/2/12 Reto Bachmann-Gmür <reto@apache.org>
> >
> > > Hi Tommaso
> > >
> > > I know. But the alternative of updating internal dependencies only
> > > when needed is quite tedious too. Also this way one can compile the
> > > clerezza trunk without downloading any clerezza dependency (i.e.
> > > offline after deleting org/apache/clerezza from the maven repository)
> > > I thing its good to have such a self-contained set of sources.
> > >
> > > Cheers,
> > > Reto
> > >
> > > On Tue, Feb 12, 2013 at 6:28 PM, Tommaso Teofili
> > > <tommaso.teofili@gmail.com> wrote:
> > > > Hi Reto,
> > > > I generally agree but I've to say it doesn't sound really smart to
> have
> > > > this back and forth version work on the branch, or at least a little
> > > > annoying for the release manager.
> > > > Apart from that +1,
> > > > Tommaso
> > > >
> > > >
> > > > 2013/2/12 Reto Bachmann-Gmür <reto@apache.org>
> > > >
> > > >> Hallo
> > > >>
> > > >> We have already been discussing this once:
> > > >>
> > > >>
> > >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-clerezza-dev/201203.mbox/%3CCAEWfVJkK4Czkwy+w3afUoKOB8i+00e4_dyQ_-2WsT1eeqZDxKQ@mail.gmail.com%3E
> > > >>
> > > >> Now also after having more experience with the stanbol approach I
> > > >> would like to suggest the following:
> > > >>
> > > >> 1) The dependency management does not contain internal dependencies
> > > >> 2) All modules in trunk depend on the latest versions of the modules
> > > >> in trunk, this is achieved by regularly running the mvn dependency
> > > >> plugin
> > > >> 3) before modules are relased they are copied to a branch and the
> > > >> trunk snapshot-version is increased
> > > >> 4) In the branch the module the dependencies to modules that are not
> > > >> part of the released are switched back to the latest released
> version
> > > >> (if incompatibilities become manifest the other modules are added
to
> > > >> the release branch)
> > > >> 5) a release is prepared on the release branch
> > > >> 6) vote
> > > >>
> > > >> The idea is to reduce to effort of developing in trunk whithout
> having
> > > >> to worry about dependencies while making it straight forward to
> > > >> release only a part of the modules.
> > > >>
> > > >>
> > > >> WDYT?
> > > >>
> > > >> Cheers,
> > > >> Reto
> > > >>
> > >
> >
>

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