Hi, For me, the one branch type of development is closer to my style. I'm that type of guy who can be easily distracted by quite anything and therefore can easily forget things. Luckily, in most cases I have automatic alerts and habits preventing disasters to happen, but there are cases when it's a bit harder to maintain.
In most of the cases (99.5%) I'm working on the next release of the package. Either by fixing bugs, following recommendations (lintian, PTS, etc) or incorporating newer versions from upstream. ANd after I finish with it, I upload the next version to unstable. But in some cases, when it better to validate my hypothesis first, I upload it to experimental. It does not happen too often (1 or 2 times annually) and therefore if I create a new branch for it, that would make me harder to not make mistakes (forget about the branch entirely, deploy it to unstable by accident or just forget to merge it at the end.) Of course, when I have to fix something in a more "prod" environment while I'm targeting my uploads to experimental, I still can create ephemeral branches, correctly targeting them to the right release and do a small fix there (hopefully by cherry-picking the fix from the latest, so that will not be a problem if I forgot to merge it back). Another problem of mine with creating different branches (and therefore I like to avoid them) is the Changelog file, which makes the cross- merges a bit more complicated than what is healthy for me. Of course my packages are small and the chance that a newer release breaks something fundamental is subtle, so it is low risk to target unstable mst of the time. On Sun, 2020-08-30 at 21:33 +0200, Mathias Behrle wrote: > * Simon McVittie: " Re: RFC: Final update of DEP-14 on naming of git > packaging > branches" (Sun, 30 Aug 2020 15:02:35 +0100): > > > On Sun, 30 Aug 2020 at 15:36:53 +0200, Raphael Hertzog wrote: > > > If I know that the next upstream release > > > breaks backwards compatitibly and that it will have to mature a > > > long time > > > in experimental until all other packages are ready, I might start > > > to > > > package it rigth now in debian/experimental and continue to use > > > debian/latest for my unstable uploads. > > > > If that's your workflow (the same as src:dbus, where versions > > 1.13.x > > are a development branch not recommended for general use), then I > > don't > > think debian/latest is a good name for that branch, and I'd > > recommend > > using debian/unstable for your unstable uploads. > > > > Rationale: it seems very confusing if a branch with "latest" in its > > name > > does not contain the newest available version :-) > > +1 > > Additionally I think explicit is usually better than implicit. When > all other > branches are named following their suites why should we diverge for > this special > case? > > > (debian/master didn't have that problem because it's named by > > analogy > > to the "master" branch used in upstream git repositories, which > > doesn't > > really have a fixed meaning anyway.) > > BTW the same applies for me to the (re-)naming of the 'default' > branch > (currently master). If it is the default branch the most plausible > name is just > 'default'. > >