[Pkg-javascript-devel] git-buildpackage workflow

[Jérémy Lal]

On 15/12/2012 21:27, Jonas Smedegaard wrote:
> Quoting Jérémy Lal (2012-12-15 20:32:35)
>> i want to switch to a simpler and more efficient way
>> of using gbp branches for the packages i am maintaining :
>>
>> * always import on "upstream" branch
>> * work on latest versions is made on "master" branch
>> * create branches of "master" when needed, but use them
>>   only for bug fixing (typically: "master-wheezy")
>>
>> No more master-experimental, upstream-experimental couples
> 
> How then to handle cases where latest upstream version is not latest 
> *stable* upstream version?
> 
> I mean - a very common use for the experimental suite is to try out 
> newer upstream releases known to not yet be mature enough for unstable.

The problem i have is having to merge master-experimental
onto master. It doesn't work well, it ends up not being
a merge at all, rather a rewrite upon (an auxiliary branch
is needed to simulate git merge --theirs by using a reverse
git merge --ours).

Let me simulate some work on package xxx :

* import 1.4.1 to upstream and merge to master
* work on master
* release 1.4.1-1 to unstable
* import 2.0 to upstream and merge to master
* work on master
* release 2.0-1 to experimental
* import 1.4.2 to upstream
  oops !

I agree that "keeping only one upstream branch" cannot work.
Last step should be :

* branch upstream-1.4 upstream/1.4.1
* branch master-1.4 debian/1.4.1-1
* import 1.4.2 to upstream-1.4 and merge to master-1.4
* work on master-1.4
* release 1.4.2-1 to unstable

I recognize it is unavoidable to have couples of branches
like here (master-1.4, upstream-1.4).
However, the latest version eventually is the stable one,
and when it does it is already on the main branch.

The model i propose is just about branching off when dealing
with stable version :
(master, upstream) -> (master-1.4, upstream-1.4)
in order to always keep latest version on (master, upstream).

This avoids the first problem, while having a very similar
structure of repository.

Jérémy.