[Rock-dev] Release: How to drop packages ?

[Janosch Machowinski]

Hm,
would the deprecation mechanism not
break existing releases ? AFAIK the release
works on the master package set. So if a
package es deprecated or removed, this
automatically applies to all releases...
Greetings
     Janosch


Am 23.04.2015 um 14:52 schrieb Sylvain Joyeux:
> The mechanism to deprecate packages has already been discussed once.
> The idea was to add a deprecated_packages marker that would 'exclude'
> the package *and* add a way to force building excluded packages.
>
>  From the user point of view, what would happen is that its build would
> fail with an error message mentioning that (1) the package is
> deprecated, (2) how to use it anyways and (3) that he won't be able to
> use it in future releases unless he copies the package definition into
> its own package sets.
>
> After one release cycle, the package could be simply removed from the
> package sets. If said users
>
> The implementation of "forcing the build of packages" was to add them
> explicitely to the layout: section in autoproj/manifest. That has
> unintended consequences
> (https://github.com/rock-core/autoproj/issues/58). I proposed two
> alternatives in the discussion, but then I and Alex dropped the
> matter:
>   - add a ! tag in the package name in the layout to say (do it !)
>   - add a forced_packages section to list packages that should be built
> no matter what
>
> Sylvain
>
> On Tue, Apr 21, 2015 at 7:58 AM, Janosch Machowinski
> <Janosch.Machowinski at dfki.de> wrote:
>> Hm,
>> what about moving the package to a "unmaintained"
>> or "attic" package set ?
>> Greetings
>>       Janosch
>>
>> Am 21.04.2015 um 11:02 schrieb Steffen Planthaber:
>>> Hi,
>>>
>>> I'd recommend to only comment the package out for at least one release
>>> cycle. This way, the package can be found, in case it is searched for.
>>>
>>> Or should we add a "removed_package" type, that instead of downloading
>>> and building the package only prints a message that the package was
>>> removed and state its original url?
>>>
>>> Steffen
>>>
>>> Am 21.04.2015 um 10:50 schrieb Matthias Goldhoorn:
>>>> On 21.04.2015 10:46, Janosch Machowinski wrote:
>>>>> Hey,
>>>>> I got a package that is ancient and outdated.
>>>>> How is the workflow for dropping it ?
>>>>> Do a merge request to remove it from the package set ?
>>>>> Greetings
>>>>>          Janosch
>>>>>
>>>> Moin moin,
>>>>
>>>> I would recomment to remove it from master but (as long it is not
>>>> broken) let it active in the release.
>>>> ..in the package_set
>>>>
>>>>
>>>> Best,
>>>> Matthias
>>>>
>>>>
>>
>> --
>>    Dipl. Inf. Janosch Machowinski
>>    SAR- & Sicherheitsrobotik
>>
>>    Universität Bremen
>>    FB 3 - Mathematik und Informatik
>>    AG Robotik
>>    Robert-Hooke-Straße 1
>>    28359 Bremen, Germany
>>
>>    Zentrale: +49 421 178 45-6611
>>
>>    Besuchsadresse der Nebengeschäftstelle:
>>    Robert-Hooke-Straße 5
>>    28359 Bremen, Germany
>>
>>    Tel.:    +49 421 178 45-6614
>>    Empfang: +49 421 178 45-6600
>>    Fax:     +49 421 178 45-4150
>>    E-Mail:  jmachowinski at informatik.uni-bremen.de
>>
>>    Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
>>
>> _______________________________________________
>> Rock-dev mailing list
>> Rock-dev at dfki.de
>> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev


-- 
  Dipl. Inf. Janosch Machowinski
  SAR- & Sicherheitsrobotik

  Universität Bremen
  FB 3 - Mathematik und Informatik
  AG Robotik
  Robert-Hooke-Straße 1
  28359 Bremen, Germany
  
  Zentrale: +49 421 178 45-6611
  
  Besuchsadresse der Nebengeschäftstelle:
  Robert-Hooke-Straße 5
  28359 Bremen, Germany
  
  Tel.:    +49 421 178 45-6614
  Empfang: +49 421 178 45-6600
  Fax:     +49 421 178 45-4150
  E-Mail:  jmachowinski at informatik.uni-bremen.de

  Weitere Informationen: http://www.informatik.uni-bremen.de/robotik