You aren't *supposed* to commit to tags, though. On Tue, Aug 4, 2009 at 5:00 AM, Martijn Dashorst<martijn.dasho...@gmail.com> 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<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 > >
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
