Thomas Vandahl wrote:
Scott Eade wrote:
* We need to build the release. Does someone want to volunteer to
be the release manager? Knowledge of this process is the main
thing that has been holding back jcs releases in the past. I
suggest that we allow someone with the necessary knowledge perform
this role for the proposed release, but they keep the list
informed of the tasks that are done so that others can do this in
the future.
Ok, if nobody else steps up, I'll do it. Should be less work than a
Torque release. My guideline always has been
http://jakarta.apache.org/commons/releases/index.html and I hope this
applies here as well.
I will be using the maven1 build as far as possible. I'm not quite sure
what the vote-after-release policy really means so I propose to cut an
RC, put it on people.apache.org somewhere, vote on it and re-brand it as
1.3.0 if everything is ok. Is that the way o go?
There has been a discussion concerning "vote-after-release" (more
correctly labelled "voting on artificats, the not the state of the
tree") on jakarta-general over the last day or so. Because various
artefacts get embedded in jars, gz files, etc., I am inclined to agree
with Henri's approach which would be to actually build 1.3 final (as
opposed to 1.3-rc1) and deploy it to your ~tv site on people.apache.org
- when the vote concludes it can then just be moved as is without any
need to do renames that might impact checksums and whatnot. If re were
building a release candidate we would do the same thing with -rc*, but
in this case I believe the right thing to do is to go straight to a
final release. My justification for this is that a number of us are
running the trunk code in production systems currently and there have
been no changes that are revolutionary in nature over the last few months.
Thanks for taking on this task Thomas.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
