On 9/16/19 23:20 , Ryan Schmidt wrote: > On Sep 15, 2019, at 22:31, Eric F (iEFdev) wrote: >> What would be better (ie good “portiquette”)… Adding subports (keeping the >> variants), or replacing variants with subports? > Provide only one way for a user to install a feature. Convert variants to > subports, if appropriate. Thanks Ryan! Yes, I guess that's the best way, and cleaner.
> Usually if a variant changes names we keep a compatibility variant around for > a time. For example, if a port provided a variant X which a user may have > installed, and then we change the variant name to Y, we keep a variant X > that's marked as requiring variant Y. When the user upgrades their > installation, they will automatically get the new variant Y (and the old > variant X which now does nothing). After a sufficient period of time to allow > all users to have upgraded (we usually recommend one year), the old variant X > can be removed. > > Converting variants to subports may or may not allow that same easy upgrade > path to take place. For example, if the new subport has a dependency on the > main port, you cannot make the old variant depend on the new subport, because > that would introduce a circular dependency. One possibility in that case is > to leave a compatibility variant for a time that does nothing but print an > error message telling the user to install the subport. I made a PR yesterday »» <https://github.com/macports/macports-ports/pull/5284>, and that was what I had i mind. It will work both ways - as subports, but still be able to use it the same way as before (didn't want to break anything). And if the variants have to go (later), one could put everything in a switch later, or something like that. If that approach is ok, perhaps I should add an err-msg like that to it? Err, or note? · Eric
