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 <[email protected]> wrote: > Hi, > > Am 19. März 2012 14:36 schrieb Daniel Spicar <[email protected]>: > > 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 >
