svn commit: r358821 - in head: . contrib/amd libexec/rc/rc.d release tools/build/mk tools/build/options usr.sbin usr.sbin/amd usr.sbin/newsyslog/newsyslog.conf.d

[Rodney W. Grimes]

> In message <202003101541.02AFfpiY065653 at gndrsh.dnsmgr.net>, "Rodney W. 
> Grimes"
> writes:
> > > On March 10, 2020 6:42:30 AM PDT, Ed Maste <emaste at 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                                                 rgrimes at freebsd.org