Well, think about it this way. In the original message in this thread, Thomas Singer went looking for the 1.4.0 release stuff at the URL:
http://svn.apache.org/repos/asf/wicket/tags/wicket-1.4.0 and it wasn't there. Why did he go there? Hmmmmmm. Maybe because that's how everyone else does it? Why would Wicket choose to do it differently than everyone else? It just doesn't make any sense to me. Also, in the vote thread, Igor proposed to release 1.4.0 from the following SVN URL: https://svn.apache.org/repos/asf/wicket/sandbox/ivaynberg/wicket-1.4.0 However, you're saying that it was actually released from: https://svn.apache.org/repos/asf/wicket/releases/wicket-1.4.0 So, the released software wasn't built from the URL the community voted on. You can't just move things around and release it. You need to release from the SVN URL in the vote thread, because that's what's being voted upon. On Tue, Aug 4, 2009 at 5:28 AM, Martijn Dashorst<martijn.dasho...@gmail.com> wrote: > tags/foo is as mutable as releases/foo > > If a release needs to be cut, we can just do: > > svn co https://svn.apache.org/repos/asf/wicket/releases/wicket-1.4.0 > ./release.sh > > there are no changes to the release after it has been created. A > social convention, just as tagging it. > > And this is the last thing I'll say about it. > > Martijn > > On Tue, Aug 4, 2009 at 11:10 AM, James > Carman<jcar...@carmanconsulting.com> wrote: >> On Tue, Aug 4, 2009 at 5:05 AM, Martijn >> Dashorst<martijn.dasho...@gmail.com> wrote: >>> We create a branch of off trunk for future maintenance of wicket 1.4, >>> not from a release branch. >>> >>> wicket/branches/wicket-1.3.x -> created from wicket/trunk when we >>> moved 1.3 to maintenance mode >>> wicket/branches/wicket-1.4.x -> will be created from wicket/trunk when >>> we move 1.4 to mainenance mode >>> >>> wicket/releases/wicket-1.4.1 -> will be created from wicket/trunk if >>> we haven't created branches/wicket-1.4.x yet, or else from >>> branches/wicket-1.4.x >>> >>> Sorry, but this has been the way we have done things since the dawn of >>> the project. Just because you think it is not correct, doesn't >>> invalidate how *we* do things. >> >> Correct. Projects do have some leeway, but it is important to be able >> to re-create the release as it was. With your strategy, you have no >> idea (without some SVN version magic) how to re-create it if you're >> checking code into the SVN URL that is used to create the release. >> The SCM URL in your released pom points to: >> >> scm:svn:http://svn.apache.org/repos/asf/wicket/releases/wicket-1.4.0 >> >> Which is MUTABLE with your strategy! You don't see a problem with >> that?!?!?! The SCM URL for releases should point to a tag (which >> nobody is supposed to modify), not a branch. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com > Apache Wicket 1.4 increases type safety for web applications > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0 > > --------------------------------------------------------------------- > 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
