[Rock-dev] Preparing a release of rock-core

[Sylvain Joyeux]

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 <bir.sylvain at gmail.com> 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
> <Steffen.Planthaber at dfki.de> 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
>>> Rock-dev at 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.Planthaber at 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 at dfki.de
>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev