I use Mercurial for commercial software development that requires
tracking of when fixes were added by release. Yet I have found little
use for naming a branch before we are preparing for a release. We know
that changes move to default between releases were for the following
release. The only reason I see for naming the current development
branch is if there are multiple parallel development efforts that could
each lead to a release. This would be true if there was a large project
that may or may not make the next feature release.
We typically branch when a we cut the first release candidate and
suspend pushing active development updates while it is in QA (probably
not strictly necessary but it speeds up the merge to default when
someone pushes a fix to the release branch). Fixes are pushed to the
release branch and merged to default. When a release candidate is
approved for customer distribution, those with un-pushed commits
pull-merge any fixes that have been merged from the release branch to
default and then do their pushes to default (they can actually do the
pull-merge whenever they want but most usually wait until the release is
out the door so they only have to fix up conflicts once).
Steve Borho wrote:
> On Fri, Jul 24, 2009 at 1:38 PM, Adrian Buehlmann<adr...@cadifra.com> wrote:
>
>> On 24.07.2009 20:01, Steve Borho wrote:
>>
>>> On Fri, Jul 24, 2009 at 12:26 PM, Adrian Buehlmann<adr...@cadifra.com>
>>> wrote:
>>>
>>>> On 24.07.2009 17:58, Steve Borho wrote:
>>>>
>>>>> Now that 0.8.1 is out the door, it's time to concentrate on 0.9.
>>>>>
>>>>> The first large steps will be happening soon. I am going to apply
>>>>> names to the two existing lines of development. The 0.8 line of
>>>>> development, which is present in both the stable and crew
>>>>> repositories, will be given a branch name of '0.8'. The 0.9 line of
>>>>> development, which is only present on the crew repository, will be
>>>>> given a branch name of '0.9'.
>>>>>
>>>> I think setting a branch name for 0.9 *now* is rather bad idea, IMHO.
>>>> This should simply be the default branch now.
>>>>
>>>> Main development ("trunk") should happen in default branch.
>>>>
>>>> This also fits with what you get when you do a fresh clone: Mercurial
>>>> updates to the tip of default branch.
>>>>
>>>> Feature freeze of 0.9 should be the earliest birthday of the 0.9 branch.
>>>>
>>> There do seem to be two schools of thought about branches. One is for
>>> release "trains" that start immediately after the current branch goes
>>> stable. The other is to have a main trunk for continual development
>>> and for branches to be created when you want to make a release.
>>>
>>> In practice, the only difference seems to be that the development
>>> leading up to the each release is not on any branch. Do you prefer
>>> the development trunk approach for the semantics of branch == "bug
>>> fixes only" and default/trunk == "where features get added"?
>>>
>> I fail to see the point in answering this question.
>>
>> What's the problem in simply continuing on default branch for non-0.8
>> stuff right now?
>>
>
> The difference is that three years from now the changes made while
> building 0.9 will be tagged as 0.9 changes. That may be a small
> difference, but I would like to make an educated choice about which
> way we do this. So I need to weigh it against the benefits of late
> branching.
>
>
>> What's the default branch intended for?
>>
>
> There's no hard-fast rule that says you must have a default branch.
> But I do understand that hg treats it specially in some instances.
>
> --
> Steve
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Tortoisehg-discuss mailing list
> Tortoisehg-discuss@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
>
>
--
Charles Simon
Principal Software Engineer
Select Business Solutions, Inc.
35 Nutmeg Drive
Trumbull, CT 06611
http://www.selectbs.com
mailto:charles.si...@selectbs.com
------------------------------------------------------------------------------
_______________________________________________
Tortoisehg-discuss mailing list
Tortoisehg-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
