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

[Janosch Machowinski]

Am 25.05.2017 um 14:57 schrieb Sylvain Joyeux:
> Since there is no other comments, I'll start by moving iodrivers_base
> to rock-core (package set and github).
move only the entry in the package set, but leave the repos were they 
are, please.
Greetings
     Janosch
>
> 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
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev