On Jul 5, 2015, at 9:30 AM, Mihai Moldovan wrote:
> On 05.07.2015 10:32 AM, Ryan Schmidt wrote:
>>> On Jul 2, 2015, at 11:14 AM, [email protected] wrote:
>>> +# Remove after 06-28-2016.
>>> +variant mp3 description {Legacy compatibility variant for MP3 support via
>>> mpg123. Will be removed soon.} {
>>> + notes-append "
>>> + You have enabled the legacy mp3 variant.
>>> + Upstream ceased using mpg123 in version 0.8.0 and
>>> removed support
>>> + completely in 0.9.0.
>>> + Decoding and playback of MP3 content is still available
>>> via
>>> + ffmpeg, so no action is needed on your side.
>>> + "
>>> }
>>
>> If no action is needed on the user's part to continue to get mp3 support,
>> then there is no reason not to remove the variant immediately. Keeping the
>> variant only serves to confuse the user by printing a pointless message, and
>> causes the user to have a non-default set of variants, meaning if there were
>> binaries of this port, the user wouldn't be able to get them until they
>> manually deselected this variant.
>
> Hum, okay.
>
> I only know the policy of keeping any variant to be removed around as a legacy
> variant that does nothing for a year to provide a better upgrade path.
>
> Also, if I just removed the mp3 variant, I feared users might panic and think
> that MP3 playback is unsupported now (which is obviously not the case.)
>
> Are you sure that's not breaking the previously mentioned policy?
The legacy compatibility variants we keep around for a year never do nothing.
They always do something: specifically, they ensure that a user who had
installed a port with a particular selected variant will, after an upgrade,
still have the same functionality, if it is still available.
For example, if a variant has changed names, and the new variant is not a
default variant, then keep the old variant around, marked as requiring the new
variant:
variant oldvariant requires newvariant description {Legacy compatibility
variant} {}
But if the commands in the old variant are no longer available and there is
either no longer a way to get that functionality or that functionality is now
enabled by default, then keeping the old variant serves no purpose so it should
be removed.
I don't think users will panic if a variant disappears. It's quite normal for a
maintainer to either fold formerly variant behavior into the default condition
of the port (because having fewer choices is better), or else to break formerly
default behavior out into a variant (perhaps because a library it depends on
would affect the distributability of the port).
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
