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<jcar...@carmanconsulting.com> 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<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 > > -- 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
