> In message <202003101541.02affpiy065...@gndrsh.dnsmgr.net>, "Rodney W. > Grimes" > writes: > > > On March 10, 2020 6:42:30 AM PDT, Ed Maste <ema...@freebsd.org> wrote: > > > >> Sorry for being snippy. It's a bad day here, client-wise, and it's > > > >spilling > > > >> over here. > > > > > > > >No apology necessary, I'm sorry I didn't coordinate more closely with > > > >you on the actual svn commit. I had this change in my WIP tree since > > > >November and just got back to it. Given the elapsed time since we last > > > >discussed it I ought to have sent a reminder/refreshed the discussion. > > > > > > I think a FreeBSD version bump might still be needed. Though ports or > > > other > > software might simply check for the existence of /usr/sbin/amd instead. > > > > > > I should put a deprecation flag into the port though I haven't thought > > > abou > > t the expiry date yet. Probably at 12 EOL. > > > > Since 13 is not going to include amd that would be ending both the base and > > p > > ort version at the same time, perhaps keep the port to 13.0 EOL to give a > > sli > > ght window when someone upgrades to 13 and finds out amd is gone they can > > go > > to the port for a quick but short lived fixed. > > > > Perhaps big giant warnings all over the port too that it is about to EOL? > > Does adding DEPRECATED= without EXPIRATION_DATE= and a comment to add > EXPIRATION_DATE for 13 EOL date sound ok?
Sounds ok, but I was thinking 13.0 EOL, vs 13 EOL, unless you want to support it for 5 more years?? Or even 13.1 EOL if it is desirable to give them just a wee bit more time. > DEPRECATED prints warnings. Ok -- Rod Grimes rgri...@freebsd.org _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
