I too am a bit worried.. A temporary fix could be to include the svn revision number for the release. Until this gets fixed.
At work, we have a special profile for hudson which does the mvn release:prepare release:perform, which does the release and tag + deploy in one go. The idea are if hudson can perform the release from scratch (checking out into a clean workspace) then the process should be replicable by everybody else. I might be missing the larger picture. But for me it would horrible if something got lost in the process.. 2009/8/4 James Carman <jcar...@carmanconsulting.com>: > On Tue, Aug 4, 2009 at 7:54 AM, Martijn > Dashorst<martijn.dasho...@gmail.com> wrote: >> We have documented, and established release procedures, which I >> followed, and then I must jump to your bidding? > > Again, the point is that we shouldn't have to read the release > procedures to find the release tags. Maven/Subversion folks just > expect things to be in certain places. It's not my bidding. > >> >> Why is it so difficult to understand that our releases/* directory is >> where we keep our release builds? And that they constitute our >> official place for checking out release code? >> > > Oh, I understand it now that we've had this long-winded email > conversation. Wouldn't it have been easier if you didn't have to > explain your non-standard release practices? > >> svn co releases/wicket-1.4.0 >> mvn install >> >> There is your 99.9% exact copy of wicket 1.4.0 (Maven modifies dates, >> so you'll never get 100% signature proof re-builds) >> > > The code in that branch has changed since the branch was created. > It's not an immutable "snapshot" like a tag is (yes, I understand that > every URL is just as immutable as the next, but the accepted paradigm > is that tags are not changed). > > Is it really so difficult for you guys to release like the rest of the > world does? If you would like help coming up with a new release plan, > I don't mind helping. We could borrow from Apache Commons. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org