Re: SVN URL for Wicket 1.4.0 sources?
fixed On Tue, Aug 4, 2009 at 9:57 AM, Thomas Singer wrote: > We include the Wicket sources using an SVN external. I now wanted to update > from the latest Wicket 1.3.* release > (http://svn.apache.org/repos/asf/wicket/tags/wicket-1.3.6) to 1.4.0, but > could not find a corresponding tag or branch. The latest one to find is for > wicket-1.4-rc5. Where can I find it? > > Thanks in advance, > Tom > > - > 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
Re: SVN URL for Wicket 1.4.0 sources?
That's not exactly fixing it, Martijn. The version in the pom still says "SNAPSHOT." What did you do, copy trunk? Who cut this release? There should be a tag available to re-create every release. I don't see tags for the last couple of rcs either. This is quite a big no-no in Apache Land. On Tue, Aug 4, 2009 at 4:14 AM, Martijn Dashorst wrote: > fixed > > On Tue, Aug 4, 2009 at 9:57 AM, Thomas Singer wrote: >> We include the Wicket sources using an SVN external. I now wanted to update >> from the latest Wicket 1.3.* release >> (http://svn.apache.org/repos/asf/wicket/tags/wicket-1.3.6) to 1.4.0, but >> could not find a corresponding tag or branch. The latest one to find is for >> wicket-1.4-rc5. Where can I find it? >> >> Thanks in advance, >> Tom >> >> - >> 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
Re: SVN URL for Wicket 1.4.0 sources?
I beg to differ: the way it is currently setup is the way we have done it since inception of wicket. tag -> the moment where we cut the release release -> the branch where the commits go to actually build the release Martijn On Tue, Aug 4, 2009 at 10:20 AM, James Carman wrote: > That's not exactly fixing it, Martijn. The version in the pom still > says "SNAPSHOT." What did you do, copy trunk? > > Who cut this release? There should be a tag available to re-create > every release. I don't see tags for the last couple of rcs either. > This is quite a big no-no in Apache Land. > > On Tue, Aug 4, 2009 at 4:14 AM, Martijn > Dashorst wrote: >> fixed >> >> On Tue, Aug 4, 2009 at 9:57 AM, Thomas Singer wrote: >>> We include the Wicket sources using an SVN external. I now wanted to update >>> from the latest Wicket 1.3.* release >>> (http://svn.apache.org/repos/asf/wicket/tags/wicket-1.3.6) to 1.4.0, but >>> could not find a corresponding tag or branch. The latest one to find is for >>> wicket-1.4-rc5. Where can I find it? >>> >>> Thanks in advance, >>> Tom >>> >>> - >>> 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 > > -- 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
Re: SVN URL for Wicket 1.4.0 sources?
see http://svn.apache.org/repos/asf/wicket/releases/wicket-1.4.0 Martijn On Tue, Aug 4, 2009 at 10:25 AM, Martijn Dashorst wrote: > I beg to differ: the way it is currently setup is the way we have done > it since inception of wicket. > > tag -> the moment where we cut the release > release -> the branch where the commits go to actually build the release > > Martijn > > On Tue, Aug 4, 2009 at 10:20 AM, James > Carman wrote: >> That's not exactly fixing it, Martijn. The version in the pom still >> says "SNAPSHOT." What did you do, copy trunk? >> >> Who cut this release? There should be a tag available to re-create >> every release. I don't see tags for the last couple of rcs either. >> This is quite a big no-no in Apache Land. >> >> On Tue, Aug 4, 2009 at 4:14 AM, Martijn >> Dashorst wrote: >>> fixed >>> >>> On Tue, Aug 4, 2009 at 9:57 AM, Thomas Singer wrote: We include the Wicket sources using an SVN external. I now wanted to update from the latest Wicket 1.3.* release (http://svn.apache.org/repos/asf/wicket/tags/wicket-1.3.6) to 1.4.0, but could not find a corresponding tag or branch. The latest one to find is for wicket-1.4-rc5. Where can I find it? Thanks in advance, Tom - 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 >> >> > > > > -- > 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 > -- 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
Re: SVN URL for Wicket 1.4.0 sources?
On Tue, Aug 4, 2009 at 4:25 AM, Martijn
Dashorst wrote:
> I beg to differ: the way it is currently setup is the way we have done
> it since inception of wicket.
No, I beg to differ. You haven't been doing it that way. Take a look at:
http://svn.apache.org/repos/asf/wicket/tags/wicket-1.3.6/pom.xml
That is a release tag and it doesn't have a SNAPSHOT version.
>
> tag -> the moment where we cut the release
> release -> the branch where the commits go to actually build the release
Tags are supposed to be immutable. What would be the purpose of
creating a SNAPSHOT tag, unless you're taking a snapshot of the source
before some major refactoring or something? The wicket-{release
version} tags should be reserved for release tags (and thus the
pom.xml wouldn't have SNAPSHOT versions in them). The release tags
should be able to be used to re-create the release. You have to have
a tag for that or else your "release" branch (which you said gets
committed to) would be altered and it would differ from the actual
release (and thus you wouldn't be able to re-create the original
release with it easily).
Why would you go against the way that everyone else uses SVN?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: SVN URL for Wicket 1.4.0 sources?
Thank you. Tom Martijn Dashorst wrote: > fixed - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: SVN URL for Wicket 1.4.0 sources?
This has been the process since I've been release manager. Create tag
when we cut the release, create release branch where we build the
release from the tag, release it. If there's a issue, repeat. This way
release artifacts don't pollute the main development stream, which is
rather normal SVN usage. This way you don't have release specific
commits pollute the diffs between releases. Only actual commits that
are part of our normal development cycle are between release *tags*.
Everything else that is specific for a release is in the release
branch. And each release gets its own release branch.
I'm not sure why you are barking up the tree though.
Martijn
On Tue, Aug 4, 2009 at 10:32 AM, James
Carman wrote:
> On Tue, Aug 4, 2009 at 4:25 AM, Martijn
> Dashorst wrote:
>> I beg to differ: the way it is currently setup is the way we have done
>> it since inception of wicket.
>
> No, I beg to differ. You haven't been doing it that way. Take a look at:
>
> http://svn.apache.org/repos/asf/wicket/tags/wicket-1.3.6/pom.xml
>
> That is a release tag and it doesn't have a SNAPSHOT version.
>
>>
>> tag -> the moment where we cut the release
>> release -> the branch where the commits go to actually build the release
>
> Tags are supposed to be immutable. What would be the purpose of
> creating a SNAPSHOT tag, unless you're taking a snapshot of the source
> before some major refactoring or something? The wicket-{release
> version} tags should be reserved for release tags (and thus the
> pom.xml wouldn't have SNAPSHOT versions in them). The release tags
> should be able to be used to re-create the release. You have to have
> a tag for that or else your "release" branch (which you said gets
> committed to) would be altered and it would differ from the actual
> release (and thus you wouldn't be able to re-create the original
> release with it easily).
>
> Why would you go against the way that everyone else uses SVN?
>
> -
> 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
Re: SVN URL for Wicket 1.4.0 sources?
See also: http://cwiki.apache.org/confluence/display/WICKET/Releasing
On Tue, Aug 4, 2009 at 10:41 AM, Martijn
Dashorst wrote:
> This has been the process since I've been release manager. Create tag
> when we cut the release, create release branch where we build the
> release from the tag, release it. If there's a issue, repeat. This way
> release artifacts don't pollute the main development stream, which is
> rather normal SVN usage. This way you don't have release specific
> commits pollute the diffs between releases. Only actual commits that
> are part of our normal development cycle are between release *tags*.
> Everything else that is specific for a release is in the release
> branch. And each release gets its own release branch.
>
> I'm not sure why you are barking up the tree though.
>
> Martijn
>
> On Tue, Aug 4, 2009 at 10:32 AM, James
> Carman wrote:
>> On Tue, Aug 4, 2009 at 4:25 AM, Martijn
>> Dashorst wrote:
>>> I beg to differ: the way it is currently setup is the way we have done
>>> it since inception of wicket.
>>
>> No, I beg to differ. You haven't been doing it that way. Take a look at:
>>
>> http://svn.apache.org/repos/asf/wicket/tags/wicket-1.3.6/pom.xml
>>
>> That is a release tag and it doesn't have a SNAPSHOT version.
>>
>>>
>>> tag -> the moment where we cut the release
>>> release -> the branch where the commits go to actually build the release
>>
>> Tags are supposed to be immutable. What would be the purpose of
>> creating a SNAPSHOT tag, unless you're taking a snapshot of the source
>> before some major refactoring or something? The wicket-{release
>> version} tags should be reserved for release tags (and thus the
>> pom.xml wouldn't have SNAPSHOT versions in them). The release tags
>> should be able to be used to re-create the release. You have to have
>> a tag for that or else your "release" branch (which you said gets
>> committed to) would be altered and it would differ from the actual
>> release (and thus you wouldn't be able to re-create the original
>> release with it easily).
>>
>> Why would you go against the way that everyone else uses SVN?
>>
>> -
>> 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
>
--
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
Re: SVN URL for Wicket 1.4.0 sources?
Ok, so show me how you would re-create the 1.4.0 release as it was
when it was released. What SVN URL would you use to do that? If
someone has checked in changes into your "release branch", you're
going to need to find what version (SVN version) was used along with
that URL to re-create the 1.4.0 release. It doesn't make sense to
have a non-SNAPSHOT version in your branch. Once a release is out,
it's out. You can't re-release 1.4.0 with different source code
(you'd have to do a 1.4.1 release).
This is *not* normal SVN usage. Take a look at:
http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html
1. Developers commit all new work to the trunk. Day-to-day changes
are committed to /trunk: new features, bug fixes, and so on.
2. The trunk is copied to a “release” branch. When the team thinks
the software is ready for release (say, a 1.0 release), /trunk might
be copied to /branches/1.0.
3. Teams continue to work in parallel. One team begins rigorous
testing of the release branch, while another team continues new work
(say, for version 2.0) on /trunk. If bugs are discovered in either
location, fixes are ported back and forth as necessary. At some point,
however, even that process stops. The branch is “frozen” for final
testing right before a release.
4. The branch is tagged and released. When testing is complete,
/branches/1.0 is copied to /tags/1.0.0 as a reference snapshot. The
tag is packaged and released to customers.
5. The branch is maintained over time. While work continues on
/trunk for version 2.0, bug fixes continue to be ported from /trunk to
/branches/1.0. When enough bug fixes have accumulated, management may
decide to do a 1.0.1 release: /branches/1.0 is copied to /tags/1.0.1,
and the tag is packaged and released.
I'm "barking up the tree" because I am a member of the Wicket
community and an Apache Software Foundation member. We need to make
sure we're doing things the right way. The right way should coincide
with the way other folks reasonably expect it to work. This is not
how the Maven release plugin does releases. It does it like this
(which is the normal way Maven/SVN folks expect releases to work):
* Check that there are no uncommitted changes in the sources
* Check that there are no SNAPSHOT dependencies
* Change the version in the poms from x-SNAPSHOT to a new version
(you will be prompted for the versions to use)
* Transform the SCM information in the POM to include the final
destination of the tag
* Run the project tests against the modified POMs to confirm
everything is in working order
* Commit the modified POMs
* Tag the code in the SCM with a version name (this will be prompted for)
* Bump the version in the POMs to a new value y-SNAPSHOT (these
values will also be prompted for)
* Commit the modified POMs
On Tue, Aug 4, 2009 at 4:41 AM, Martijn
Dashorst wrote:
> This has been the process since I've been release manager. Create tag
> when we cut the release, create release branch where we build the
> release from the tag, release it. If there's a issue, repeat. This way
> release artifacts don't pollute the main development stream, which is
> rather normal SVN usage. This way you don't have release specific
> commits pollute the diffs between releases. Only actual commits that
> are part of our normal development cycle are between release *tags*.
> Everything else that is specific for a release is in the release
> branch. And each release gets its own release branch.
>
> I'm not sure why you are barking up the tree though.
>
> Martijn
>
> On Tue, Aug 4, 2009 at 10:32 AM, James
> Carman wrote:
>> On Tue, Aug 4, 2009 at 4:25 AM, Martijn
>> Dashorst wrote:
>>> I beg to differ: the way it is currently setup is the way we have done
>>> it since inception of wicket.
>>
>> No, I beg to differ. You haven't been doing it that way. Take a look at:
>>
>> http://svn.apache.org/repos/asf/wicket/tags/wicket-1.3.6/pom.xml
>>
>> That is a release tag and it doesn't have a SNAPSHOT version.
>>
>>>
>>> tag -> the moment where we cut the release
>>> release -> the branch where the commits go to actually build the release
>>
>> Tags are supposed to be immutable. What would be the purpose of
>> creating a SNAPSHOT tag, unless you're taking a snapshot of the source
>> before some major refactoring or something? The wicket-{release
>> version} tags should be reserved for release tags (and thus the
>> pom.xml wouldn't have SNAPSHOT versions in them). The release tags
>> should be able to be used to re-create the release. You have to have
>> a tag for that or else your "release" branch (which you said gets
>> committed to) would be altered and it would differ from the actual
>> release (and thus you wouldn't be able to re-create the original
>> release with it easily).
>>
>> Why would you go against the way that everyone else uses SVN?
>>
>> -
>> To u
Re: SVN URL for Wicket 1.4.0 sources?
I don't disagree that you guys are doing it this way. I'm saying it's
the wrong way to do it.
On Tue, Aug 4, 2009 at 4:45 AM, Martijn
Dashorst wrote:
> See also: http://cwiki.apache.org/confluence/display/WICKET/Releasing
>
> On Tue, Aug 4, 2009 at 10:41 AM, Martijn
> Dashorst wrote:
>> This has been the process since I've been release manager. Create tag
>> when we cut the release, create release branch where we build the
>> release from the tag, release it. If there's a issue, repeat. This way
>> release artifacts don't pollute the main development stream, which is
>> rather normal SVN usage. This way you don't have release specific
>> commits pollute the diffs between releases. Only actual commits that
>> are part of our normal development cycle are between release *tags*.
>> Everything else that is specific for a release is in the release
>> branch. And each release gets its own release branch.
>>
>> I'm not sure why you are barking up the tree though.
>>
>> Martijn
>>
>> On Tue, Aug 4, 2009 at 10:32 AM, James
>> Carman wrote:
>>> On Tue, Aug 4, 2009 at 4:25 AM, Martijn
>>> Dashorst wrote:
I beg to differ: the way it is currently setup is the way we have done
it since inception of wicket.
>>>
>>> No, I beg to differ. You haven't been doing it that way. Take a look at:
>>>
>>> http://svn.apache.org/repos/asf/wicket/tags/wicket-1.3.6/pom.xml
>>>
>>> That is a release tag and it doesn't have a SNAPSHOT version.
>>>
tag -> the moment where we cut the release
release -> the branch where the commits go to actually build the release
>>>
>>> Tags are supposed to be immutable. What would be the purpose of
>>> creating a SNAPSHOT tag, unless you're taking a snapshot of the source
>>> before some major refactoring or something? The wicket-{release
>>> version} tags should be reserved for release tags (and thus the
>>> pom.xml wouldn't have SNAPSHOT versions in them). The release tags
>>> should be able to be used to re-create the release. You have to have
>>> a tag for that or else your "release" branch (which you said gets
>>> committed to) would be altered and it would differ from the actual
>>> release (and thus you wouldn't be able to re-create the original
>>> release with it easily).
>>>
>>> Why would you go against the way that everyone else uses SVN?
>>>
>>> -
>>> 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
>>
>
>
>
> --
> 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
Re: SVN URL for Wicket 1.4.0 sources?
I can commit to a tag just as good as to the release branch. There is no spoon.
Martijn
On Tue, Aug 4, 2009 at 10:56 AM, James
Carman wrote:
> Ok, so show me how you would re-create the 1.4.0 release as it was
> when it was released. What SVN URL would you use to do that? If
> someone has checked in changes into your "release branch", you're
> going to need to find what version (SVN version) was used along with
> that URL to re-create the 1.4.0 release. It doesn't make sense to
> have a non-SNAPSHOT version in your branch. Once a release is out,
> it's out. You can't re-release 1.4.0 with different source code
> (you'd have to do a 1.4.1 release).
>
> This is *not* normal SVN usage. Take a look at:
>
> http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html
>
> 1. Developers commit all new work to the trunk. Day-to-day changes
> are committed to /trunk: new features, bug fixes, and so on.
> 2. The trunk is copied to a “release” branch. When the team thinks
> the software is ready for release (say, a 1.0 release), /trunk might
> be copied to /branches/1.0.
> 3. Teams continue to work in parallel. One team begins rigorous
> testing of the release branch, while another team continues new work
> (say, for version 2.0) on /trunk. If bugs are discovered in either
> location, fixes are ported back and forth as necessary. At some point,
> however, even that process stops. The branch is “frozen” for final
> testing right before a release.
> 4. The branch is tagged and released. When testing is complete,
> /branches/1.0 is copied to /tags/1.0.0 as a reference snapshot. The
> tag is packaged and released to customers.
> 5. The branch is maintained over time. While work continues on
> /trunk for version 2.0, bug fixes continue to be ported from /trunk to
> /branches/1.0. When enough bug fixes have accumulated, management may
> decide to do a 1.0.1 release: /branches/1.0 is copied to /tags/1.0.1,
> and the tag is packaged and released.
>
> I'm "barking up the tree" because I am a member of the Wicket
> community and an Apache Software Foundation member. We need to make
> sure we're doing things the right way. The right way should coincide
> with the way other folks reasonably expect it to work. This is not
> how the Maven release plugin does releases. It does it like this
> (which is the normal way Maven/SVN folks expect releases to work):
>
> * Check that there are no uncommitted changes in the sources
> * Check that there are no SNAPSHOT dependencies
> * Change the version in the poms from x-SNAPSHOT to a new version
> (you will be prompted for the versions to use)
> * Transform the SCM information in the POM to include the final
> destination of the tag
> * Run the project tests against the modified POMs to confirm
> everything is in working order
> * Commit the modified POMs
> * Tag the code in the SCM with a version name (this will be prompted for)
> * Bump the version in the POMs to a new value y-SNAPSHOT (these
> values will also be prompted for)
> * Commit the modified POMs
>
>
> On Tue, Aug 4, 2009 at 4:41 AM, Martijn
> Dashorst wrote:
>> This has been the process since I've been release manager. Create tag
>> when we cut the release, create release branch where we build the
>> release from the tag, release it. If there's a issue, repeat. This way
>> release artifacts don't pollute the main development stream, which is
>> rather normal SVN usage. This way you don't have release specific
>> commits pollute the diffs between releases. Only actual commits that
>> are part of our normal development cycle are between release *tags*.
>> Everything else that is specific for a release is in the release
>> branch. And each release gets its own release branch.
>>
>> I'm not sure why you are barking up the tree though.
>>
>> Martijn
>>
>> On Tue, Aug 4, 2009 at 10:32 AM, James
>> Carman wrote:
>>> On Tue, Aug 4, 2009 at 4:25 AM, Martijn
>>> Dashorst wrote:
I beg to differ: the way it is currently setup is the way we have done
it since inception of wicket.
>>>
>>> No, I beg to differ. You haven't been doing it that way. Take a look at:
>>>
>>> http://svn.apache.org/repos/asf/wicket/tags/wicket-1.3.6/pom.xml
>>>
>>> That is a release tag and it doesn't have a SNAPSHOT version.
>>>
tag -> the moment where we cut the release
release -> the branch where the commits go to actually build the release
>>>
>>> Tags are supposed to be immutable. What would be the purpose of
>>> creating a SNAPSHOT tag, unless you're taking a snapshot of the source
>>> before some major refactoring or something? The wicket-{release
>>> version} tags should be reserved for release tags (and thus the
>>> pom.xml wouldn't have SNAPSHOT versions in them). The release tags
>>> should be able to be used to re-create the release. You have to have
>>> a tag for that or else your "release" branch (which you said gets
>>> committed to) would be altered and it w
Re: SVN URL for Wicket 1.4.0 sources?
You aren't *supposed* to commit to tags, though.
On Tue, Aug 4, 2009 at 5:00 AM, Martijn
Dashorst wrote:
> I can commit to a tag just as good as to the release branch. There is no
> spoon.
>
> Martijn
>
> On Tue, Aug 4, 2009 at 10:56 AM, James
> Carman wrote:
>> Ok, so show me how you would re-create the 1.4.0 release as it was
>> when it was released. What SVN URL would you use to do that? If
>> someone has checked in changes into your "release branch", you're
>> going to need to find what version (SVN version) was used along with
>> that URL to re-create the 1.4.0 release. It doesn't make sense to
>> have a non-SNAPSHOT version in your branch. Once a release is out,
>> it's out. You can't re-release 1.4.0 with different source code
>> (you'd have to do a 1.4.1 release).
>>
>> This is *not* normal SVN usage. Take a look at:
>>
>> http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html
>>
>> 1. Developers commit all new work to the trunk. Day-to-day changes
>> are committed to /trunk: new features, bug fixes, and so on.
>> 2. The trunk is copied to a “release” branch. When the team thinks
>> the software is ready for release (say, a 1.0 release), /trunk might
>> be copied to /branches/1.0.
>> 3. Teams continue to work in parallel. One team begins rigorous
>> testing of the release branch, while another team continues new work
>> (say, for version 2.0) on /trunk. If bugs are discovered in either
>> location, fixes are ported back and forth as necessary. At some point,
>> however, even that process stops. The branch is “frozen” for final
>> testing right before a release.
>> 4. The branch is tagged and released. When testing is complete,
>> /branches/1.0 is copied to /tags/1.0.0 as a reference snapshot. The
>> tag is packaged and released to customers.
>> 5. The branch is maintained over time. While work continues on
>> /trunk for version 2.0, bug fixes continue to be ported from /trunk to
>> /branches/1.0. When enough bug fixes have accumulated, management may
>> decide to do a 1.0.1 release: /branches/1.0 is copied to /tags/1.0.1,
>> and the tag is packaged and released.
>>
>> I'm "barking up the tree" because I am a member of the Wicket
>> community and an Apache Software Foundation member. We need to make
>> sure we're doing things the right way. The right way should coincide
>> with the way other folks reasonably expect it to work. This is not
>> how the Maven release plugin does releases. It does it like this
>> (which is the normal way Maven/SVN folks expect releases to work):
>>
>> * Check that there are no uncommitted changes in the sources
>> * Check that there are no SNAPSHOT dependencies
>> * Change the version in the poms from x-SNAPSHOT to a new version
>> (you will be prompted for the versions to use)
>> * Transform the SCM information in the POM to include the final
>> destination of the tag
>> * Run the project tests against the modified POMs to confirm
>> everything is in working order
>> * Commit the modified POMs
>> * Tag the code in the SCM with a version name (this will be prompted for)
>> * Bump the version in the POMs to a new value y-SNAPSHOT (these
>> values will also be prompted for)
>> * Commit the modified POMs
>>
>>
>> On Tue, Aug 4, 2009 at 4:41 AM, Martijn
>> Dashorst wrote:
>>> This has been the process since I've been release manager. Create tag
>>> when we cut the release, create release branch where we build the
>>> release from the tag, release it. If there's a issue, repeat. This way
>>> release artifacts don't pollute the main development stream, which is
>>> rather normal SVN usage. This way you don't have release specific
>>> commits pollute the diffs between releases. Only actual commits that
>>> are part of our normal development cycle are between release *tags*.
>>> Everything else that is specific for a release is in the release
>>> branch. And each release gets its own release branch.
>>>
>>> I'm not sure why you are barking up the tree though.
>>>
>>> Martijn
>>>
>>> On Tue, Aug 4, 2009 at 10:32 AM, James
>>> Carman wrote:
On Tue, Aug 4, 2009 at 4:25 AM, Martijn
Dashorst wrote:
> I beg to differ: the way it is currently setup is the way we have done
> it since inception of wicket.
No, I beg to differ. You haven't been doing it that way. Take a look at:
http://svn.apache.org/repos/asf/wicket/tags/wicket-1.3.6/pom.xml
That is a release tag and it doesn't have a SNAPSHOT version.
>
> tag -> the moment where we cut the release
> release -> the branch where the commits go to actually build the release
Tags are supposed to be immutable. What would be the purpose of
creating a SNAPSHOT tag, unless you're taking a snapshot of the source
before some major refactoring or something? The wicket-{release
version} tags should be reserved for release tags (and thus the
pom.xml wouldn't have SNAPSHOT versions in
Re: SVN URL for Wicket 1.4.0 sources?
Take a look at: http://svnbook.red-bean.com/en/1.5/svn.branchmerge.tags.html#svn.branchmerge.tags.mksimple "But wait a moment: isn't this tag creation procedure the same procedure we used to create a branch? Yes, in fact, it is. In Subversion, there's no difference between a tag and a branch. Both are just ordinary directories that are created by copying. Just as with branches, the only reason a copied directory is a “tag” is because humans have decided to treat it that way: as long as nobody ever commits to the directory, it forever remains a snapshot. If people start committing to it, it becomes a branch. If you are administering a repository, there are two approaches you can take to managing tags. The first approach is “hands off”: as a matter of project policy, decide where your tags will live, and make sure all users know how to treat the directories they copy. (That is, make sure they know not to commit to them.) The second approach is more paranoid: you can use one of the access control scripts provided with Subversion to prevent anyone from doing anything but creating new copies in the tags area (see Chapter 6, Server Configuration). The paranoid approach, however, isn't usually necessary. If a user accidentally commits a change to a tag directory, you can simply undo the change as discussed in the previous section. This is version control, after all!" On Tue, Aug 4, 2009 at 5:02 AM, James Carman wrote: > You aren't *supposed* to commit to tags, though. > > On Tue, Aug 4, 2009 at 5:00 AM, Martijn > Dashorst wrote: >> I can commit to a tag just as good as to the release branch. There is no >> spoon. >> >> Martijn >> >> On Tue, Aug 4, 2009 at 10:56 AM, James >> Carman wrote: >>> Ok, so show me how you would re-create the 1.4.0 release as it was >>> when it was released. What SVN URL would you use to do that? If >>> someone has checked in changes into your "release branch", you're >>> going to need to find what version (SVN version) was used along with >>> that URL to re-create the 1.4.0 release. It doesn't make sense to >>> have a non-SNAPSHOT version in your branch. Once a release is out, >>> it's out. You can't re-release 1.4.0 with different source code >>> (you'd have to do a 1.4.1 release). >>> >>> This is *not* normal SVN usage. Take a look at: >>> >>> http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html >>> >>> 1. Developers commit all new work to the trunk. Day-to-day changes >>> are committed to /trunk: new features, bug fixes, and so on. >>> 2. The trunk is copied to a “release” branch. When the team thinks >>> the software is ready for release (say, a 1.0 release), /trunk might >>> be copied to /branches/1.0. >>> 3. Teams continue to work in parallel. One team begins rigorous >>> testing of the release branch, while another team continues new work >>> (say, for version 2.0) on /trunk. If bugs are discovered in either >>> location, fixes are ported back and forth as necessary. At some point, >>> however, even that process stops. The branch is “frozen” for final >>> testing right before a release. >>> 4. The branch is tagged and released. When testing is complete, >>> /branches/1.0 is copied to /tags/1.0.0 as a reference snapshot. The >>> tag is packaged and released to customers. >>> 5. The branch is maintained over time. While work continues on >>> /trunk for version 2.0, bug fixes continue to be ported from /trunk to >>> /branches/1.0. When enough bug fixes have accumulated, management may >>> decide to do a 1.0.1 release: /branches/1.0 is copied to /tags/1.0.1, >>> and the tag is packaged and released. >>> >>> I'm "barking up the tree" because I am a member of the Wicket >>> community and an Apache Software Foundation member. We need to make >>> sure we're doing things the right way. The right way should coincide >>> with the way other folks reasonably expect it to work. This is not >>> how the Maven release plugin does releases. It does it like this >>> (which is the normal way Maven/SVN folks expect releases to work): >>> >>> * Check that there are no uncommitted changes in the sources >>> * Check that there are no SNAPSHOT dependencies >>> * Change the version in the poms from x-SNAPSHOT to a new version >>> (you will be prompted for the versions to use) >>> * Transform the SCM information in the POM to include the final >>> destination of the tag >>> * Run the project tests against the modified POMs to confirm >>> everything is in working order >>> * Commit the modified POMs >>> * Tag the code in the SCM with a version name (this will be prompted for) >>> * Bump the version in the POMs to a new value y-SNAPSHOT (these >>> values will also be prompted for) >>> * Commit the modified POMs >>> >>> >>> On Tue, Aug 4, 2009 at 4:41 AM, Martijn >>> Dashorst wrote: This has been the process since I've been release manager. Create tag when we cut the release, create release branch where we build the relea
Re: SVN URL for Wicket 1.4.0 sources?
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. Martijn On Tue, Aug 4, 2009 at 10:56 AM, James Carman wrote: > Ok, so show me how you would re-create the 1.4.0 release as it was > when it was released. What SVN URL would you use to do that? If > someone has checked in changes into your "release branch", you're > going to need to find what version (SVN version) was used along with > that URL to re-create the 1.4.0 release. It doesn't make sense to > have a non-SNAPSHOT version in your branch. Once a release is out, > it's out. You can't re-release 1.4.0 with different source code > (you'd have to do a 1.4.1 release). > > This is *not* normal SVN usage. Take a look at: > > http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html > > 1. Developers commit all new work to the trunk. Day-to-day changes > are committed to /trunk: new features, bug fixes, and so on. > 2. The trunk is copied to a “release” branch. When the team thinks > the software is ready for release (say, a 1.0 release), /trunk might > be copied to /branches/1.0. > 3. Teams continue to work in parallel. One team begins rigorous > testing of the release branch, while another team continues new work > (say, for version 2.0) on /trunk. If bugs are discovered in either > location, fixes are ported back and forth as necessary. At some point, > however, even that process stops. The branch is “frozen” for final > testing right before a release. > 4. The branch is tagged and released. When testing is complete, > /branches/1.0 is copied to /tags/1.0.0 as a reference snapshot. The > tag is packaged and released to customers. > 5. The branch is maintained over time. While work continues on > /trunk for version 2.0, bug fixes continue to be ported from /trunk to > /branches/1.0. When enough bug fixes have accumulated, management may > decide to do a 1.0.1 release: /branches/1.0 is copied to /tags/1.0.1, > and the tag is packaged and released. > > I'm "barking up the tree" because I am a member of the Wicket > community and an Apache Software Foundation member. We need to make > sure we're doing things the right way. The right way should coincide > with the way other folks reasonably expect it to work. This is not > how the Maven release plugin does releases. It does it like this > (which is the normal way Maven/SVN folks expect releases to work): > > * Check that there are no uncommitted changes in the sources > * Check that there are no SNAPSHOT dependencies > * Change the version in the poms from x-SNAPSHOT to a new version > (you will be prompted for the versions to use) > * Transform the SCM information in the POM to include the final > destination of the tag > * Run the project tests against the modified POMs to confirm > everything is in working order > * Commit the modified POMs > * Tag the code in the SCM with a version name (this will be prompted for) > * Bump the version in the POMs to a new value y-SNAPSHOT (these > values will also be prompted for) > * Commit the modified POMs > > > On Tue, Aug 4, 2009 at 4:41 AM, Martijn > Dashorst wrote: >> This has been the process since I've been release manager. Create tag >> when we cut the release, create release branch where we build the >> release from the tag, release it. If there's a issue, repeat. This way >> release artifacts don't pollute the main development stream, which is >> rather normal SVN usage. This way you don't have release specific >> commits pollute the diffs between releases. Only actual commits that >> are part of our normal development cycle are between release *tags*. >> Everything else that is specific for a release is in the release >> branch. And each release gets its own release branch. >> >> I'm not sure why you are barking up the tree though. >> >> Martijn >> >> On Tue, Aug 4, 2009 at 10:32 AM, James >> Carman wrote: >>> On Tue, Aug 4, 2009 at 4:25 AM, Martijn >>> Dashorst wrote: I beg to differ: the way it is currently setup is the way we have done it since inception of wicket. >>> >>> No, I beg to differ. You haven't been doing it that way. Take a look at: >>> >>> http://svn.apache.org/repos/asf/wicket/tags/wicket-1.3.6/pom.xml >>> >>> That is a release tag and it doesn't have a SNAPSHOT version. >>> tag -> the moment where we cut the release release -> the branch where the commits go to actually build the release >>> >>> Ta
Re: SVN URL for Wicket 1.4.0 sources?
Same for releases/wicket-1.4.0 after the release has been created. Martijn On Tue, Aug 4, 2009 at 11:02 AM, James Carman wrote: > You aren't *supposed* to commit to tags, though. > > On Tue, Aug 4, 2009 at 5:00 AM, Martijn > Dashorst wrote: >> I can commit to a tag just as good as to the release branch. There is no >> spoon. >> >> Martijn >> >> On Tue, Aug 4, 2009 at 10:56 AM, James >> Carman wrote: >>> Ok, so show me how you would re-create the 1.4.0 release as it was >>> when it was released. What SVN URL would you use to do that? If >>> someone has checked in changes into your "release branch", you're >>> going to need to find what version (SVN version) was used along with >>> that URL to re-create the 1.4.0 release. It doesn't make sense to >>> have a non-SNAPSHOT version in your branch. Once a release is out, >>> it's out. You can't re-release 1.4.0 with different source code >>> (you'd have to do a 1.4.1 release). >>> >>> This is *not* normal SVN usage. Take a look at: >>> >>> http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html >>> >>> 1. Developers commit all new work to the trunk. Day-to-day changes >>> are committed to /trunk: new features, bug fixes, and so on. >>> 2. The trunk is copied to a “release” branch. When the team thinks >>> the software is ready for release (say, a 1.0 release), /trunk might >>> be copied to /branches/1.0. >>> 3. Teams continue to work in parallel. One team begins rigorous >>> testing of the release branch, while another team continues new work >>> (say, for version 2.0) on /trunk. If bugs are discovered in either >>> location, fixes are ported back and forth as necessary. At some point, >>> however, even that process stops. The branch is “frozen” for final >>> testing right before a release. >>> 4. The branch is tagged and released. When testing is complete, >>> /branches/1.0 is copied to /tags/1.0.0 as a reference snapshot. The >>> tag is packaged and released to customers. >>> 5. The branch is maintained over time. While work continues on >>> /trunk for version 2.0, bug fixes continue to be ported from /trunk to >>> /branches/1.0. When enough bug fixes have accumulated, management may >>> decide to do a 1.0.1 release: /branches/1.0 is copied to /tags/1.0.1, >>> and the tag is packaged and released. >>> >>> I'm "barking up the tree" because I am a member of the Wicket >>> community and an Apache Software Foundation member. We need to make >>> sure we're doing things the right way. The right way should coincide >>> with the way other folks reasonably expect it to work. This is not >>> how the Maven release plugin does releases. It does it like this >>> (which is the normal way Maven/SVN folks expect releases to work): >>> >>> * Check that there are no uncommitted changes in the sources >>> * Check that there are no SNAPSHOT dependencies >>> * Change the version in the poms from x-SNAPSHOT to a new version >>> (you will be prompted for the versions to use) >>> * Transform the SCM information in the POM to include the final >>> destination of the tag >>> * Run the project tests against the modified POMs to confirm >>> everything is in working order >>> * Commit the modified POMs >>> * Tag the code in the SCM with a version name (this will be prompted for) >>> * Bump the version in the POMs to a new value y-SNAPSHOT (these >>> values will also be prompted for) >>> * Commit the modified POMs >>> >>> >>> On Tue, Aug 4, 2009 at 4:41 AM, Martijn >>> Dashorst wrote: This has been the process since I've been release manager. Create tag when we cut the release, create release branch where we build the release from the tag, release it. If there's a issue, repeat. This way release artifacts don't pollute the main development stream, which is rather normal SVN usage. This way you don't have release specific commits pollute the diffs between releases. Only actual commits that are part of our normal development cycle are between release *tags*. Everything else that is specific for a release is in the release branch. And each release gets its own release branch. I'm not sure why you are barking up the tree though. Martijn On Tue, Aug 4, 2009 at 10:32 AM, James Carman wrote: > On Tue, Aug 4, 2009 at 4:25 AM, Martijn > Dashorst wrote: >> I beg to differ: the way it is currently setup is the way we have done >> it since inception of wicket. > > No, I beg to differ. You haven't been doing it that way. Take a look at: > > http://svn.apache.org/repos/asf/wicket/tags/wicket-1.3.6/pom.xml > > That is a release tag and it doesn't have a SNAPSHOT version. > >> >> tag -> the moment where we cut the release >> release -> the branch where the commits go to actually build the release > > Tags are supposed to be immutable. What would be the purpose of > creating a SNAPSHOT tag,
Re: SVN URL for Wicket 1.4.0 sources?
On Tue, Aug 4, 2009 at 5:00 AM, Martijn Dashorst wrote: > I can commit to a tag just as good as to the release branch. There is no > spoon. You're not answering the question, either. You haven't shown me how you would easily re-create the released software as it was when it was released with your current source control strategy. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: SVN URL for Wicket 1.4.0 sources?
On Tue, Aug 4, 2009 at 5:05 AM, Martijn Dashorst 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
Re: SVN URL for Wicket 1.4.0 sources?
You might want to check the best practices document from the Incubator: http://incubator.apache.org/guides/releasemanagement.html#best-practices-svn On Tue, Aug 4, 2009 at 5:05 AM, Martijn Dashorst wrote: > Same for releases/wicket-1.4.0 after the release has been created. > > Martijn > > On Tue, Aug 4, 2009 at 11:02 AM, James > Carman wrote: >> You aren't *supposed* to commit to tags, though. >> >> On Tue, Aug 4, 2009 at 5:00 AM, Martijn >> Dashorst wrote: >>> I can commit to a tag just as good as to the release branch. There is no >>> spoon. >>> >>> Martijn >>> >>> On Tue, Aug 4, 2009 at 10:56 AM, James >>> Carman wrote: Ok, so show me how you would re-create the 1.4.0 release as it was when it was released. What SVN URL would you use to do that? If someone has checked in changes into your "release branch", you're going to need to find what version (SVN version) was used along with that URL to re-create the 1.4.0 release. It doesn't make sense to have a non-SNAPSHOT version in your branch. Once a release is out, it's out. You can't re-release 1.4.0 with different source code (you'd have to do a 1.4.1 release). This is *not* normal SVN usage. Take a look at: http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html 1. Developers commit all new work to the trunk. Day-to-day changes are committed to /trunk: new features, bug fixes, and so on. 2. The trunk is copied to a “release” branch. When the team thinks the software is ready for release (say, a 1.0 release), /trunk might be copied to /branches/1.0. 3. Teams continue to work in parallel. One team begins rigorous testing of the release branch, while another team continues new work (say, for version 2.0) on /trunk. If bugs are discovered in either location, fixes are ported back and forth as necessary. At some point, however, even that process stops. The branch is “frozen” for final testing right before a release. 4. The branch is tagged and released. When testing is complete, /branches/1.0 is copied to /tags/1.0.0 as a reference snapshot. The tag is packaged and released to customers. 5. The branch is maintained over time. While work continues on /trunk for version 2.0, bug fixes continue to be ported from /trunk to /branches/1.0. When enough bug fixes have accumulated, management may decide to do a 1.0.1 release: /branches/1.0 is copied to /tags/1.0.1, and the tag is packaged and released. I'm "barking up the tree" because I am a member of the Wicket community and an Apache Software Foundation member. We need to make sure we're doing things the right way. The right way should coincide with the way other folks reasonably expect it to work. This is not how the Maven release plugin does releases. It does it like this (which is the normal way Maven/SVN folks expect releases to work): * Check that there are no uncommitted changes in the sources * Check that there are no SNAPSHOT dependencies * Change the version in the poms from x-SNAPSHOT to a new version (you will be prompted for the versions to use) * Transform the SCM information in the POM to include the final destination of the tag * Run the project tests against the modified POMs to confirm everything is in working order * Commit the modified POMs * Tag the code in the SCM with a version name (this will be prompted for) * Bump the version in the POMs to a new value y-SNAPSHOT (these values will also be prompted for) * Commit the modified POMs On Tue, Aug 4, 2009 at 4:41 AM, Martijn Dashorst wrote: > This has been the process since I've been release manager. Create tag > when we cut the release, create release branch where we build the > release from the tag, release it. If there's a issue, repeat. This way > release artifacts don't pollute the main development stream, which is > rather normal SVN usage. This way you don't have release specific > commits pollute the diffs between releases. Only actual commits that > are part of our normal development cycle are between release *tags*. > Everything else that is specific for a release is in the release > branch. And each release gets its own release branch. > > I'm not sure why you are barking up the tree though. > > Martijn > > On Tue, Aug 4, 2009 at 10:32 AM, James > Carman wrote: >> On Tue, Aug 4, 2009 at 4:25 AM, Martijn >> Dashorst wrote: >>> I beg to differ: the way it is currently setup is the way we have done >>> it since inception of wicket. >> >> No, I beg to differ. You haven't been doing it that way. Take a look >> at: >> >> http://svn.apache.org/repos/asf/wicket/tags/wicket-1.3.6/pom.xml
Re: SVN URL for Wicket 1.4.0 sources?
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 wrote: > On Tue, Aug 4, 2009 at 5:05 AM, Martijn > Dashorst 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
Re: SVN URL for Wicket 1.4.0 sources?
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? Hmm. 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 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 wrote: >> On Tue, Aug 4, 2009 at 5:05 AM, Martijn >> Dashorst 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
Re: SVN URL for Wicket 1.4.0 sources?
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? Hmm. 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 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 wrote: On Tue, Aug 4, 2009 at 5:05 AM, Martijn Dashorst 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
Re: SVN URL for Wicket 1.4.0 sources?
WTF? Read the commit messages and then tell me that the 1.4.0 release is not an exact copy of sandbox/ivaynberg/wicket-1.4.0 ? Martijn On Tue, Aug 4, 2009 at 12:33 PM, James Carman wrote: > 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? Hmm. 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 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 wrote: >>> On Tue, Aug 4, 2009 at 5:05 AM, Martijn >>> Dashorst 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 > > -- 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
Re: SVN URL for Wicket 1.4.0 sources?
We shouldn't have to do this kind of research to know what's going on. That's the whole point. On Tue, Aug 4, 2009 at 7:25 AM, Martijn Dashorst wrote: > WTF? > > Read the commit messages and then tell me that the 1.4.0 release is > not an exact copy of sandbox/ivaynberg/wicket-1.4.0 ? > > Martijn > > On Tue, Aug 4, 2009 at 12:33 PM, James > Carman wrote: >> 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? Hmm. 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 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 wrote: On Tue, Aug 4, 2009 at 5:05 AM, Martijn Dashorst 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 >> >> > > > > -- > 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
Re: SVN URL for Wicket 1.4.0 sources?
Jeez, get a life... Martijn On Tue, Aug 4, 2009 at 1:29 PM, James Carman wrote: > We shouldn't have to do this kind of research to know what's going on. > That's the whole point. > > On Tue, Aug 4, 2009 at 7:25 AM, Martijn > Dashorst wrote: >> WTF? >> >> Read the commit messages and then tell me that the 1.4.0 release is >> not an exact copy of sandbox/ivaynberg/wicket-1.4.0 ? >> >> Martijn >> >> On Tue, Aug 4, 2009 at 12:33 PM, James >> Carman wrote: >>> 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? Hmm. 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 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 wrote: > On Tue, Aug 4, 2009 at 5:05 AM, Martijn > Dashorst 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 >>> >>> >> >> >> >> -- >> 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 > > -- Become a Wicket expert, learn from the best: http://wicket
Re: SVN URL for Wicket 1.4.0 sources?
Wow, that's a great way for a member of the development team to treat a member of their user community. I'm not the only one with these concerns. Why don't you bad-mouth Reinhard too? On Tue, Aug 4, 2009 at 7:35 AM, Martijn Dashorst wrote: > Jeez, get a life... > > Martijn > > On Tue, Aug 4, 2009 at 1:29 PM, James > Carman wrote: >> We shouldn't have to do this kind of research to know what's going on. >> That's the whole point. >> >> On Tue, Aug 4, 2009 at 7:25 AM, Martijn >> Dashorst wrote: >>> WTF? >>> >>> Read the commit messages and then tell me that the 1.4.0 release is >>> not an exact copy of sandbox/ivaynberg/wicket-1.4.0 ? >>> >>> Martijn >>> >>> On Tue, Aug 4, 2009 at 12:33 PM, James >>> Carman wrote: 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? Hmm. 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 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 wrote: >> On Tue, Aug 4, 2009 at 5:05 AM, Martijn >> Dashorst 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 >>> >>> >>> >>> -- >>> 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: use
Re: SVN URL for Wicket 1.4.0 sources?
We have documented, and established release procedures, which I followed, and then I must jump to your 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? 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) Martijn On Tue, Aug 4, 2009 at 1:47 PM, James Carman wrote: > Wow, that's a great way for a member of the development team to treat > a member of their user community. I'm not the only one with these > concerns. Why don't you bad-mouth Reinhard too? > > On Tue, Aug 4, 2009 at 7:35 AM, Martijn > Dashorst wrote: >> Jeez, get a life... >> >> Martijn >> >> On Tue, Aug 4, 2009 at 1:29 PM, James >> Carman wrote: >>> We shouldn't have to do this kind of research to know what's going on. >>> That's the whole point. >>> >>> On Tue, Aug 4, 2009 at 7:25 AM, Martijn >>> Dashorst wrote: WTF? Read the commit messages and then tell me that the 1.4.0 release is not an exact copy of sandbox/ivaynberg/wicket-1.4.0 ? Martijn On Tue, Aug 4, 2009 at 12:33 PM, James Carman wrote: > 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? Hmm. 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 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 wrote: >>> On Tue, Aug 4, 2009 at 5:05 AM, Martijn >>> Dashorst 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
Re: SVN URL for Wicket 1.4.0 sources?
http://svn.apache.org/repos/asf/wicket/releases/ -- Jeremy Thomerson http://www.wickettraining.com On Tue, Aug 4, 2009 at 3:20 AM, James Carman wrote: > That's not exactly fixing it, Martijn. The version in the pom still > says "SNAPSHOT." What did you do, copy trunk? > > Who cut this release? There should be a tag available to re-create > every release. I don't see tags for the last couple of rcs either. > This is quite a big no-no in Apache Land. > > On Tue, Aug 4, 2009 at 4:14 AM, Martijn > Dashorst wrote: >> fixed >> >> On Tue, Aug 4, 2009 at 9:57 AM, Thomas Singer wrote: >>> We include the Wicket sources using an SVN external. I now wanted to update >>> from the latest Wicket 1.3.* release >>> (http://svn.apache.org/repos/asf/wicket/tags/wicket-1.3.6) to 1.4.0, but >>> could not find a corresponding tag or branch. The latest one to find is for >>> wicket-1.4-rc5. Where can I find it? >>> >>> Thanks in advance, >>> Tom >>> >>> - >>> 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
Re: SVN URL for Wicket 1.4.0 sources?
On Tue, Aug 4, 2009 at 7:54 AM, Martijn Dashorst 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
Re: SVN URL for Wicket 1.4.0 sources?
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 : > On Tue, Aug 4, 2009 at 7:54 AM, Martijn > Dashorst 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
Re: SVN URL for Wicket 1.4.0 sources?
Oh and yes Wicket Devs you are doing a great job, without you there would be no wicket.. And with no wicket no happy Nino:) But just because something has done one way always it doesn't mean it's the best way. I believe creating a release should be as simple as a click :) Regards Nino 2009/8/4 nino martinez wael : > 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 : >> On Tue, Aug 4, 2009 at 7:54 AM, Martijn >> Dashorst 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
Re: SVN URL for Wicket 1.4.0 sources?
thanks, my bad. got lost in all the building and rebuilding :) -igor On Tue, Aug 4, 2009 at 1:14 AM, Martijn Dashorst wrote: > fixed > > On Tue, Aug 4, 2009 at 9:57 AM, Thomas Singer wrote: >> We include the Wicket sources using an SVN external. I now wanted to update >> from the latest Wicket 1.3.* release >> (http://svn.apache.org/repos/asf/wicket/tags/wicket-1.3.6) to 1.4.0, but >> could not find a corresponding tag or branch. The latest one to find is for >> wicket-1.4-rc5. Where can I find it? >> >> Thanks in advance, >> Tom >> >> - >> 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
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 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 : >> On Tue, Aug 4, 2009 at 7:54 AM, Martijn >> Dashorst 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
RE: SVN URL for Wicket 1.4.0 sources?
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 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 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 : >> On Tue, Aug 4, 2009 at 7:54 AM, Martijn >> Dashorst 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
Re: SVN URL for Wicket 1.4.0 sources?
I apologize for this remark. I should've taken a couple of breaths and set gmail beer goggles up. Blame it on 4 weeks of baby invoked sleep deprivation (and no, I didn't get a good nights sleep last night, 4am when the little screamer finally slept—or I passed out... not sure which one). Martijn On Tue, Aug 4, 2009 at 1:35 PM, Martijn Dashorst wrote: > Jeez, get a life... > > Martijn > > On Tue, Aug 4, 2009 at 1:29 PM, James > Carman wrote: >> We shouldn't have to do this kind of research to know what's going on. >> That's the whole point. >> >> On Tue, Aug 4, 2009 at 7:25 AM, Martijn >> Dashorst wrote: >>> WTF? >>> >>> Read the commit messages and then tell me that the 1.4.0 release is >>> not an exact copy of sandbox/ivaynberg/wicket-1.4.0 ? >>> >>> Martijn >>> >>> On Tue, Aug 4, 2009 at 12:33 PM, James >>> Carman wrote: 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? Hmm. 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 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 wrote: >> On Tue, Aug 4, 2009 at 5:05 AM, Martijn >> Dashorst 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 >>> >>> >>> >>> -- >>> 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
