svn commit: r257696 - in head: libexec/rbootd share/man/man9 sys/compat/svr4 sys/net sys/sys

[John Baldwin]

On Wednesday, November 06, 2013 1:20:29 am Gleb Smirnoff wrote:
>   John, Adrian,
> 
> On Tue, Nov 05, 2013 at 05:18:26PM -0500, John Baldwin wrote:
> J> Mmmm, people run older versions of binaries (even open source ones) on newer OS's
> J> perhaps more often than you think.   The COMPAT_43 stuff can be dropped certainly,
> J> but people will almost certainly do rolling upgrades where they upgrade the OS
> J> on their machines before they upgrade their packages.
> 
> On Tue, Nov 05, 2013 at 02:25:13PM -0800, Adrian Chadd wrote:
> A> My main worry about this kind of work is that you're just steamrolling
> A> through stuff that yes, should be done, but with little warning and no
> A> API deprecation schedule.
> A> 
> A> I'd much rather see this stuff handled more formally - we mark the API
> A> as deprecated and remove it in the next release.
> A> 
> A> I really don't like seeing steamrolling through the kernel and
> A> deprecating APIs with minimal warning and having no (optional)
> A> backwards compatibility implementations. That's what made us stand out
> A> from Linux - we kept old APIs around as much as we could. Linux wasn't
> A> terribly good at this.
> 
> One reply to both of you. The schedule is the following: we are compatible
> with previous major version. The interface had changed in early
> 10.0-CURRENT, and during the entire 10.0-CURRENT life it has supported the
> new and the old interface and this went into stable/10. When doing the change,
> I have pronounced this deprecation schedule.
> 
> If anyone upgrades to next major: 9.x -> 10.x, or 10.x -> 11.x, including
> package sets, then everything will be working for him.

As I said, you ignore users who run older binaries on a large cluster of
machines while doing staged OS upgrades.  By your logic, we shouldn't have
any COMPAT_FREEBSD<n> options at all except for <n-1>.  The presence of such
options would seem to indicate that your assumption is incorrect.

-- 
John Baldwin