Well... If we acutaly left tags alone and did not change them or retag then the tag would be sufficent. But to get an exact codeline for a specific release you need the tag + rev.
--jason -----Original Message----- From: "Alan D. Cabrera" <[EMAIL PROTECTED]> Date: Thu, 21 Dec 2006 20:55:08 To:[email protected] Subject: Re: [vote] Release geronimo-jpa_3.0_spec-1.0 I would imagine that a branch which is ready to be released would be quiessed and so there would be no need for an svn rev # or am I missing something? Regards, Alan On Dec 21, 2006, at 3:19 PM, [EMAIL PROTECTED] wrote: > IMO using a svn rev # for a release is a good idea, that with a tag > ensures that code for that exact release can always be found at a > later time. > > --jason > > > > > -----Original Message----- > From: Matt Hogstrom <[EMAIL PROTECTED]> > Date: Thu, 21 Dec 2006 18:10:46 > To:[email protected] > Subject: Re: [vote] Release geronimo-jpa_3.0_spec-1.0 > > > On Dec 21, 2006, at 4:06 PM, Guillaume Nodet wrote: > >> I think voting on svn source for small projects / jars is good, >> because people can build them locally, check that everything >> is ok (for legal reasons), and vote. This is much more difficult >> for Geronimo server, of course, and may not be applied. >> >> This works well, I think, if the release process is just >> mvn release:prepare release:perform >> which should be the case for all projects ideally. >> The benefit is that the jars will be deployed to their final >> destination >> as part of the relase, without having to tweak / corrupting maven >> repository metadata by copying from a staging repo. >> > > For my part, I'd prefer to follow this approach going forward. I > agree with Guillaume that it may not totally work for Geronimo unless > we choose an SVN number as the release point so people can track > changes to a branch. > > Having been through the release process a few times I think that > using Maven to generate the artifacts is so much simpler and > automagically updating the repo is far easier as well. > > I'd like to propose (in a separate thread) that we adopt this process > going forward for specs. If the vote succeeds then I think David > could follow it for these specs as a test case. > > Matt Hogstrom > [EMAIL PROTECTED] > >
