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

Sylvain Joyeux bir.sylvain at gmail.com
Mon May 29 15:27:24 CEST 2017 

> move only the entry in the package set, but leave the repos were they
are, please.

Why ? GitHub redirects the old URLs to the new ones, and so far all
packages in rock-core are within the rock-core organization ...
Starting to randomly have packages spread around wouldn't sound like a
great idea to me ...

If you're really afraid that the URLs stop working, we could move the
repo and create a read-only fork of it on the old place.

Sylvain

On Sun, May 28, 2017 at 2:26 PM, Janosch Machowinski
<Janosch.Machowinski at dfki.de> wrote:
> 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
>
>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

More information about the Rock-dev mailing list