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<martijn.dasho...@gmail.com> 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<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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
