> > What were your goals? > Clean history and a stable branch somewhere? > > In principle not bad. The problem is how to achieve this. >
Yes. > > You propose a <feature-branch filter> for <trunk-stable>. > > But your idea could be inverted, so it would work like with BRANCH. > Someone is responsible for <trunk-stable> and cherry-picks all the > stable features and cleans up the history That's effectively what I'm doing now behind the scenes, though there are some drawbacks: - all commits will end up twice in the history (one in 'trunk' and one in 'trunk-stable'). - people might get angry if someone starts rewriting their history they carefully composed, so better let the committer do it, - it is difficult for the 'someone' to organize other one's commits. For example, I tried to organize all the recent CMake commits. There are now 30 commits or so, some have to do with running in-place, some have to do with compiling libintl, some are just bugfixes, some are there to generalize to other platforms, and so forth. It's much easier and will cost less time for the actual committer to take care of this. > > . This way we could > "continuously" release beta quality without slowing down development > in trunk. I don't see why my proposal would slow down development. Vincent
