Hi, At DFKI we were discussing a new release for quite some time and your proposal is very welcome.
The result of our discussions was also that we should split rock-core releases from the rest. (Comments on your plan at the end). We also thought about how to "release" the rest of the packages, here is the idea (quite sililar to what ROS does), consider this a RFC: * Split the rock (not core) package_set into two sets: (maintained/unmaintained) both are specific to a single rock release (branch in the package_set?) * When a new rock release is available, all packages from maintained set of the old core version are moved to the unmaintained set of the new one, it gets a new, empty maitained package_set * To move a package from "unmaintained" to "maintained" set for a new release, the ->maintainer<- has to check his package against the new release, and create merge request to the maintained_set.This way, we can keep track of the actual maintainers of packages * Only the packages of the maintained set are checked by the buildserver/listed on the homepage and listed as "maintained there" Still, there is not much "plus" on having a own package in the maintained set, could still be that devs rather stay "unmaintained". We could also completely remove the "unmaintained" set and the package is just not available (commented out) for that release until checked. Am 17.05.2017 um 16:16 schrieb Sylvain Joyeux: > I want to prepare a release of rock.core (and only rock.core), "in its > current state" I guess the new release will be based on the master branches as done in the past? > The only change I'd like to make is to add iodrivers_base and > orogen/iodrivers_base in rock.core, as they are quite ubiquitous. > Common core libraries like opencv and pcl should IMO also Sounds fine. > Further down the road, I intend to prepare such a release on a regular > basis (hopefully at most monthly for pure bugfixes and 3 months for > breaking changes). I also want to focus on rock-core passing its own > test suite(s) - which it currently does not. I originally wanted to do > it *before* releasing, but actually getting the tests to pass require > quite a bit of changes in the packages that see little-to-no > maintenance. Noble Goal ;-) > I also intend to gradually assign version numbers (hopefully following > a semantic-versioning like scheme), and provide proper changelogs on > each version. semantic-versioning is a good choice IMO. > Comments are welcome, as usual. Barring showstoppers on this plan, > I'll do the work in the next week(s) Thanks very much. Steffen > > Sylvain > _______________________________________________ > Rock-dev mailing list > Rock-dev@dfki.de > http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev > -- Steffen Planthaber Weltraumrobotik Besuchsadresse der Nebengeschäftstelle: DFKI GmbH Robotics Innovation Center Robert-Hooke-Straße 5 28359 Bremen, Germany Postadresse der Hauptgeschäftsstelle Standort Bremen: DFKI GmbH Robotics Innovation Center Robert-Hooke-Straße 1 28359 Bremen, Germany Tel.: +49 421 178 45-4125 Zentrale: +49 421 178 45-0 Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen) E-Mail: steffen.plantha...@dfki.de Weitere Informationen: http://www.dfki.de/robotik ----------------------------------------------------------------------- Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Amtsgericht Kaiserslautern, HRB 2313 Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973 Steuernummer: 19/673/0060/3 ----------------------------------------------------------------------- _______________________________________________ Rock-dev mailing list Rock-dev@dfki.de http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
