incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Spicar <dspi...@apache.org>
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 package-info.java 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
versions.
- The launcher JAR projects will always depend on the latest (release?)
versions.

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?

Daniel

[1]
https://cwiki.apache.org/confluence/display/SLING/Thoughts+on+Release+Management
[2] http://sling.apache.org/site/version-policy.html
[3] www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf

On 19 March 2012 14:54, 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
> > 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
> http://twitter.com/fctwitt
>

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