On Jun 14, 2007, at 11:44 AM, Matt Hogstrom wrote:
On Jun 14, 2007, at 2:22 PM, David Jencks wrote:
I don't understand the release process for specs to tell what is
going on, however there is no https://svn.apache.org/repos/asf/
geronimo/specs/tags/geronimo-ws-metadata_2.0_spec-1.1.1 (what i'd
expect a 1.1.1 to be under) nor a https://svn.apache.org/repos/asf/
geronimo/specs/tags/geronimo-ws-metadata_2.0_spec-1.1 (what is
actually shown in the newly added scm info). IMO its slightly
better to have no information rather than wrong information.
Fair comment I think. For the most part few people actually follow
through to actually release software and we've done a poor job of
releasing them. IIRC Dain had indicated he would handle the specs
but in reality it needs to be a community responsibility and not
dependent on one person. So, as far as that goes, I believe we do
something different in Specs than we do for the Geronimo server and
I'm unaware of any documentation except perhaps older e-mail
threads. If there is some doc a link would be appreciated. If
there is blame to be assigned here then I spect it would be on me
and not Prasad as he asked my opinion on how to do some of this.
So with that, here is my input.
Following what we do in Geronimo (where we do not use the release
plugin for a whole raft of other reasons) the branch has been
updated to look like it will exist when it is svn mv'd to https://
svn.apache.org/repos/asf/geronimo/specs/tags/ so with that in mind
I think the SCM information is correct (or will be when the vote
concludes and the various bits are moved to their respective
locations.) I think the SCM information is nice to have.
At this point I'm
+0 on releasing the original (no scm info) ws-metadata 1.1.1 jar
-0 on releasing the modified one.
Keeping track of the spec release procedure is beyond my limited
abilities, but what is happening is not what I expected. My dim
recollections of the release procedure was that we would use the
maven release plugin and that would correctly tag the source and
generate/modify all the artifacts consistent with the new tag.
I'm confused because there is no 1.1.1 tag that I can find for ws
metadata and the scm info does not appear to be getting updated.
Is this a maven bug, is it not supposed to be updated by the
release plugin, or something else?
It is not your inability to consume them I think it is our lack of
initiative to document and follow them. Since I've been release
dog for a while I'll go hack up the CWiki and try to get this done
once and for all. However, I'll do that on another thread.
Regarding the scm tags, as I noted above, it was a manual
compromise as I rememer in the past people complaining that they
wanted to vote on binaries that were not being released rather than
what the release plugin might generate. Perhaps my inability to
recollect is contributing to this already confusing and wearing
discussion on release shtuffes.
I found this email from dain which is the last documentation on spec
releases I can find, from dec 12 2006:
Kevan asked me to go over the development/release process used when
we have a single version number.
1 Make a development module in specs/trunk
[Maintince] svn cp specs/tags/<artifactId>-<latestVersion> specs/
trunk/<artifactId>
[New] make a new mvn module at specs/trunk/<artifactId>
2 Make changes
There is no need to update inner spec depenencies since all will
be marked as scope provided in the pom, so we don't get transitive
problems.
3 Vote and Release
update pom version
create jars
vote
publish
svn mv specs/trunk/<artifactId> specs/tags/<artifactId>-<version>
Alternatively, we can use the release plugin but the release plugin
means we can't vote on the final jars since it automatically
publishes to the final repository.
BTW, I am willing to be spec release manager using this process in
perpetuity.
--------------------------
I'm pretty sure the release plugin can now push the artifacts to a
staging area , and then later actually move them to the appropriate
repo. I think it would be a good idea to investigate this and I
might even be willing to do that myself.
thanks
david jencks
