health-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Health-dev] New mercurial development branch and workflow


From: Feng Shu
Subject: Re: [Health-dev] New mercurial development branch and workflow
Date: Sun, 25 Feb 2024 08:15:21 +0800
User-agent: Gnus/5.13 (Gnus v5.13)

Luis Falcon <falcon@gnuhealth.org> writes:

> Dear devs
>
> We have a new development branch called "future" that will hold the
> upcoming stable releases.
>
> This applies to hmis server and client repositories. The current
> branches are:
>
> * stable: current stable releases
> * default: testing functionality and patches for stable releases  
> * future: new features for upcoming release 

Today, I read "A complete Mercurial branching strategy" and find some
useful informations.

https://www.draketo.de/software/mercurial-branching-strategy.html

```
1. 3 simple rules

Any model to be used by people should consist of simple, consistent
rules. Programming is complex enough without having to worry about
elaborate branching directives. Therefore this model boils down to 3
simple rules:

1. you do all the work on default - except for hotfixes.

2. on stable you only do hotfixes, merges for release and tagging for
release. Only maintainers3 touch stable.

3. you can use arbitrary feature-branches, as long as you don't call
them default or stable. They always start at default (since you do all
the work on default).

```



>
> Although the duet stable/default works, it's a bit more involved in
> major refactoring work.
>
>
> Please keep it in mind when developing. So, if we find a bug for the
> current 4.4 release, we'll fix it and test it on "default" and then
> merge it on "stable".


>From "A complete Mercurial branching strategy":


if we find a bug for the current 4.4 release, we should fix it at
"stable" branch, then we merge "stable" branch to "default" branch.


If we first fix bug and test on "default", I think we should "hg graft"
this bugfix's commit to 'stable' branch, then we merge 'stable' branch
to 'default' branch again, maybe we should solve conflict.

graft + merge approach reliable?  I haven't used it before, I don't
know. Further verification is needed.

>
> The tasks for the upcoming 5.0, we'll be worked on branch "future".

We will work 5.0 branch to 'future', when finished, will we merge
"future" to "default"? or merge to "stable" directly?


>
> As per tagging particular changesets releases, functionality remains
> happy as it is today :)
>
> All the best
> Luis

-- 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]