incubator-jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Castagna <>
Subject From snapshots to a candidate release to a release... what do you think?
Date Fri, 14 Oct 2011 17:07:27 GMT
in the Apache Maven repository we have three levels (we can and IMHO should use) before we
do a release.
There are SNAPSHOTs [1], "candidate releases" that you can publish in a staging repository
[2] and people need to test and vote against and releases [3].



During development (i.e. most of the time) we should have -SNAPSHOT dependencies between our
modules, as we are mostly already doing. This way we spot changes which are going to cause
problems in
other modules as soon and as quickly as possible (via Jenkins).

Every committer should be able to publish a SNAPSHOT (as we are and he should not be afraid
to do so). It's as simple as: mvn deploy.
The Apache Maven repository is managed with Nexus and it cleans automatically SNAPSHOTs when
there are too many.

Jenkins can also configured to automatically publish SNAPSHOTs (every night, for example).
I've added a few Jena_X_Nightly jobs just to test this and see how it goes.

We currently have two set of POMs|SNAPSHOTs for each module, old and new development repository.
The sooner we reduce this back to one (i.e. using only Apache Maven repository) the better.
confusion for us or other users/developers, less things to manage|check when there is a problem.

Candidate Releases:

In Apache we can safely release artifacts into the staging repository [2]. This is not mirrored
to Maven Central, therefore mistakes are not a problem (and we should not be afraid to do
mistakes in
the staging repository).

The release manager, once there is agreement that it's time to do a release, can publish stuff
there (it's extremely easy to do so via Maven release plugin). Once stuff is there people
can test those
candidate releases and when people feel conmfortable the [VOTE] process can start.

The candidate release can also be good to isolate people from temporary glitches with SNAPSHOTs
in particular when we are close to a release. This gives people time to properly test candidate
releases, without stopping usual development (which can proceed using SNAPSHOTs).

The staging repository can be used by others as well to easilly test our candidate releases.
Some companies use Maven internally as well as the Maven release plugin to manage their internal
If they want to test unreleased features in TDB, for example, they can point to a -SNAPSHOT
dependency, that's fine during development. However, at some point they might need to release
their stuff
internally (before we release TDB). They cannot do that pointing to a -SNAPSHOT. At that point
they need to either point to the latest TDB release (maybe missing some feature they need)
or fork TDB
sources internally and release TDB internally adding that to their dependencies. They could
(and IMHO should) depend on a candidate release, instead. This way, they also be better positioned
provide us with feedback and helping with testing what is going to be released (rather than
something different).


When a [VOTE] is successful. Stuff is moved from the stating to the release repository and
this is done (by the release manager) pressing a button (without recompiling, but copying
stuff from one
place to another).

Short summary:

 - trunk is always in development mode and dependencies on our modules are all -SNAPSHOT dependencies
 - committers can run mvn deploy whenever they need, no problem
 - we should have candidate releases in our staging repository, the release manager can put
stuff there via mvn release:prepare, etc.
 - people have three choices (level of risk/bleeding edge): snapshots (high risk), candidate
releases (medium risk), official Apache releases (low risk)

High risk == this could be bleeding edge, if you find a problem we are grateful if you report
it to us, but you should not complain about it too loudly. :-)
Overall, most of the Jena modules are quite safe and stable anyway and trunk is always in
good shape. So, high risk, in reality, is very low in comparison to other projects (which
most of the times is

Does this seem reasonable to you?


View raw message