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<martijn.dasho...@gmail.com> 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<jcar...@carmanconsulting.com> wrote:
>> On Tue, Aug 4, 2009 at 4:25 AM, Martijn
>> Dashorst<martijn.dasho...@gmail.com> 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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to