Hi, 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].
[1] https://repository.apache.org/content/repositories/snapshots/ [2] https://repository.apache.org/content/repositories/staging/ [3] https://repository.apache.org/content/repositories/releases/ SNAPSHOTs: --------- 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. Less 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 projects. 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 to provide us with feedback and helping with testing what is going to be released (rather than something different). Releases: -------- 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 good). Does this seem reasonable to you? Paolo
