On 04.12.2012, at 18:56, Pau Garcia i Quiles <[email protected]> wrote:
> > > On Tue, Dec 4, 2012 at 6:26 PM, Konstantin Tokarev <[email protected]> wrote: > > 04.12.2012, 21:02, "Pau Garcia i Quiles" <[email protected]>: > > On Tue, Dec 4, 2012 at 5:21 PM, Konstantin Tokarev <[email protected]> > > wrote: > > > >> There's no point in keeping separate branch purely for tags. It is just an > >> unnecessary overcomplication. > > Actually, there is: it allows you to continue working in stabilization > > branches, then discard those changes (i. e. never release them into master > > or the -releases branch) > > This is something you are supposed to do in topic branches, forked from > stabilization branch. Also, you have git revert for extreme cases. > > > Our workflow is a bit different, we have QA, marketing and other stakeholders > who may decide, after 3 weeks of QA validation, that the version to release > is not the tip of the -stabilization branch but an older version (we then > update -release with some older version from -stabilization). You could say > release-3.1-stabilization and release-3.1-releases are topic branches; we > don't. > > > >and it helps overcome the lack of git tags support in some continuous > >integration systems. > > Sounds weird, like it was continuous integration system without support for > branches. > > > Welcome to the wonderful world of CruiseControl.NET. Jenkins also doesn't support tags (or specific commits) …. which is … strange … But of course it's possible to workaround with branches in a non-upstream clone/mirror -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
