incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Spicar <>
Subject Re: releasing individual modules (WAS: Can someone create 0.3-incubating version in our JIRA project?)
Date Wed, 21 Mar 2012 16:08:58 GMT
I read some more about Sling's version-policy [1, 2] and I checked their
maven configurations. It may be the way to go for Clerezza as well.

Based on that I would probably go for something like this for Clerezza
(just a rough brainstorming):

- Change maven version numbers to the OSGI semantic versioning format [3].
That basically means Major.Minor.Micro(.qualifier). Additionally the
version numbers carry more semantic meaning and need to be changed
accordingly by the developers.
- The Maven version number would be the bundle version (will always be at
least the version of the highest package versions, but it may be higher.)
- Introduce package versioning (at least for packages exported by a
bundle). Use or packageinfo.txt files to version
packages. The maven-bundle plugin will then deal with the export and import
package declarations.
- For Maven projects with packaging of type 'pom' we should use just a
single integer version. Version semantics are meaningless for those
projects. They just increment on each change.
- In general all modules should depend on the oldest version of other
modules/pom-projects they need.
- Probably dependency management for our projects should be dropped because
it will become the norm for different bundles to depend on different
- The launcher JAR projects will always depend on the latest (release?)

Implications of this (not verified):
- After a release we will not update module dependencies to snapshot
versions automatically. This should only be done manually when a new
version is required for some reason.
- Probably the maven-release-plugin will not work with this workflow. It
needs to be checked how much manual work this causes.
- There will be A LOT more responsibility put on developers to manage
versions correctly and it will be required that everyone modifying code
understands the semantic versioning, package versioning, bundle versioning
and its implications.
- Not sure if this versioning scheme will cause awkward problems when
someone tries to use clerezza modules outside an OSGi environment (in
general: without some advanced class loading). But I also don't know if we
care about such a use-case.

I want to stress that this is not a finished proposal. I just put that
together from the top of my head after checking out how sling does this.

Any thoughts? Improvements? Clarifications?



On 19 March 2012 14:54, Fabian Christ <> wrote:

> Hi,
> Am 19. März 2012 14:36 schrieb Daniel Spicar <>:
> > 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
> > 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.
> Best,
>  - Fabian
> --
> Fabian

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