Time to mark portupgrade deprecated?

[Torfinn Ingolfsen]

Hi,

On Mon, Jul 25, 2011 at 1:40 PM, Chris Rees <crees at freebsd.org> wrote:
> On 25 July 2011 12:27, Torfinn Ingolfsen <tingox at gmail.com> wrote:
>> My two cents after reading this whole thread:
>>
>> like it or not, portupgrade is currently the "official" tool (it's in
>> the Handbook and all other docs).
>> So in my view, this is what needs to be done:
>> a) select a new "official tool"
>> b) create or update said tool so it is working to 95% of all the wishes
>> c) update all the documentation pointing to this new tool, and set a
>> warning ("the old tool, portupgrade, is going away in X years")
>> d) wait X years
>> e) remove portupgrade
>>
>> As Doug wrote, change is hard. But there is a difference between
>> change because all other options has run out of time, and planned
>> change.
>> We can make it less hard, at the cost of a longer timeframe.
>
> The usual process of deprecaction is to add a warning in one release,
> and then remove it in the next.
>
> While I appreciate portupgrade isn't part of the base system, I think
> this process would be appropriate.

We have lived with portupgrade for ten years or more now. Why the
sudden rush to get rid of it?
As others have stated, portupgrade is still functional, and there
isn't any "total failure" scenarios imminent that I am aware of.

In my view, change is useful in two situations:
a) when it brings in new functionality or replaces existing
functionality with better functionality
b) when it removes "dead weight", ie. non-working and non-maintained
ports or other programs, thus decreasing the load of the people who
have to maintain the code.

Since portupgrade is still functional, I would argue that b) doesn't apply.
Just my opinion.
-- 
Regards,
Torfinn Ingolfsen