Right. Doesn't everybody here understand that the completed releases are tagged in the releases directory rather than the tags.
James, I don't understand why you are so upset. Nothing is lost - it's just somewhere that you'd prefer it not to be. We like it in the releases directory because all the releases are together and not mixed in with endless arbitrary tags. If you are so concerned about it, call for a vote - don't gripe about the committers producing this framework for you. Voting is the Apache way. Jeremy Thomerson http://www.wickettraining.com -- sent from a wireless device -----Original Message----- From: Igor Vaynberg <igor.vaynb...@gmail.com> Sent: Tuesday, August 04, 2009 10:01 AM To: users@wicket.apache.org Subject: Re: SVN URL for Wicket 1.4.0 sources? nothing was lost -igor On Tue, Aug 4, 2009 at 6:51 AM, nino martinez wael<nino.martinez.w...@gmail.com> wrote: > 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 > > --------------------------------------------------------------------- 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
