The same thing happened to me recently. I wanted to check out the
release tag and could not find it. I was already sort of surprised when
Igor mentioned he'd release from his private sandbox.
And now we have a 1.4.0 tag with a 1.4-SNAPSHOT in it and trunk which
still has 1.4-SNAPSHOT. That can't be it. Please, guys, rethink your
release process. The Maven release plugin is just the standard way of
cutting releases.
Reinhard
James Carman schrieb:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
