I've created two pull requests, which will obviously need some testing ... If anyone is interested.
This is basically the option 3 described here: http://rock.opendfki.de/wiki/WikiStart/OngoingWork/RockFlavorsOrReleases/How https://github.com/rock-core/package_set/pull/12 - makes 'stable' track the rock1408 branch - makes 'next' an alias for 'stable' (for backward compatibility reasons) https://github.com/rock-core/rock-package_set/pull/19 - updates the rock package set accordingly TODO: - update the post-commit hook to warn people who commit on the stable branch DIFFERENCES WITH THE ROCK1408 BRANCH ----------------------------------------------------------------------- I've NOT moved any packages from master to stable (unlike rock1408 which moved all master packages to stable). If these PRs get accepted into the package set, I'll announce on rock-users that maintainers will have to request it explicitly. Two exceptions: base/orogen/interfaces and drivers/velodyne_lidar as they were dependencies of "released packages". The non-Rock-branched packages are NOT pinned to a particular commit. The PR contain the setup code for it, but I need to backport an autoproj patch to make it work (will do it ASAP). People using 'stable' will get switched to the new release next time we release anything. What I want is that we've ironed out the release process by then and "pin" them transparently before we release. Sylvain _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
