Andy Seaborne wrote:
Splitting out the process issues touched on:
On 25/10/11 10:21, Paolo Castagna wrote:
We do not use SNAPSHOTs when we do an internal release, therefore we
roll-out our own TDB "release" which is TDB unchanged and it was at
revision 1186734.
Why can't you use a nightly build? Isn't that what you have been
advocating?
Yes.
We use TDB 0.9.0-incubating-SNAPSHOT.
Our internal projects which depend on TDB, depends on
0.9.0-incubating-SNAPSHOT when we are in development mode.
At release time, we use mvn release plugin (which rightly so, does
not allow you to release your project until you have removed all the
-SNAPSHOT dependencies).
At that point in time, we would love to have a release candidate
we can point at. We will switch and re-run all our test (i.e. a
private Jenkins @ Talis does this for us).
It would be better to release our internal projects pointing to a
release candidate in the Apache stating repository.
Having a release candidate in the staging repository helps us and
enable better feedback. We do not need to for and release internally
Jena modules.
By the way, a release candidate in the Apache staging
repository (even if it is dropped) would help here (we would just use
and test that instead).
There various tasks that we wil have to do sometime, e.g. "Handling
Cryptography within an ASF Release"
http://www.apache.org/dev/crypto.html
http://www.apache.org/licenses/exports/
Yes.
Do we need to do these for a release candidate (which we might drop)?
Paolo
Andy
