> To reflect the two different cases, I would think of adding > autoproj tag -> create a tag with the current state in autoproj/ > autoproj commit -> update the current buildconf to pin the current state > and commit in autoproj/. The workflow is the traditional update, fix bug, > commit
Just a recap to make sure we understand the same things: autoproj commit - will take the a snapshot of the package in a buildconf, write the result to a refindex file, and may or may not (detail) call a git commit on the buildconf repo. autoproj tag - creates a tag on the current buildconf repo? Does this do anything more than calling the git tag? Maybe it would be fine then to just use the git command... Other than that, as far as I can see we discussed giving up the rolling heads (gg) model and effectively switch to releases (which I totally support). Imho there is also no point really in having a next (or replacement name) branch. They should get differentiable names or version numbers. Hey we could finally have our own release names, all derived from anything rock related. rock-star, rocker-bogie, rock-bottom... the possibilities are endless :) Cheers, Jakob _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
