Since there is no other comments, I'll start by moving iodrivers_base to rock-core (package set and github).
Sylvain On Thu, May 18, 2017 at 11:31 AM, Sylvain Joyeux <[email protected]> wrote: > I personally would prefer simply add versioning tags in the > manifest.xml, and make all packages available all the time. > Branching/splitting package sets is going to be a horrible mess, as > each release will become a major change in the git history. We've > tried that before, it just does not work (or, more accurately, > requires an amount of effort down the line that we simply don't have). > > Basically, a package is supported on a given Rock release if it has > the corresponding tag. It's up to the maintainer to update the tag. > The web page/rock-release/an autoproj v2 rock plugin would allow to > show this tag as "supported on this version or not". > > All packages are available all the time (until they are purely and > simply removed from the package sets because they're truly > unmaintained). This is actually very close to ROS: you're always > allowed to check out a package and install it. The only additional > info you have is whether the package maintainers considers the package > "maintained on this version of ROS". > > Sylvain > > On Thu, May 18, 2017 at 10:45 AM, Steffen Planthaber > <[email protected]> wrote: >> 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 >>> [email protected] >>> 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: [email protected] >> >> 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 >> [email protected] >> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
