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