Date: Wed, 6 Nov 2013 10:24:08 -0500 From: John Baldwin <jhb@freebsd.org> To: Gleb Smirnoff <glebius@freebsd.org> Cc: svn-src-head@freebsd.org, Adrian Chadd <adrian@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r257696 - in head: libexec/rbootd share/man/man9 sys/compat/svr4 sys/net sys/sys Message-ID: <201311061024.09200.jhb@freebsd.org> In-Reply-To: <20131106062029.GP7577@FreeBSD.org> References: <20131106062029.GP7577@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201311061024.09200.jhb>