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

[Sylvain Joyeux]

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