From owner-freebsd-hackers@FreeBSD.ORG Wed May 21 20:40:16 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F077443 for ; Wed, 21 May 2014 20:40:16 +0000 (UTC) Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5C1F22DA9 for ; Wed, 21 May 2014 20:40:16 +0000 (UTC) Received: from bigmac.router9fbd7c.com (unknown [176.222.238.90]) by csmtp2.one.com (Postfix) with ESMTPA id CF34E4000A2E1; Wed, 21 May 2014 20:31:21 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: [GSoC] Machine readable output from userland utilities From: Erik Cederstrand In-Reply-To: <537CD1EE.2000708@mu.org> Date: Wed, 21 May 2014 22:31:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <49E9736E-AD14-4647-8B15-30603D01360C@mail.bg> <91FE2526-F21C-42AB-BECB-058DBA975A9E@cederstrand.dk> <537C2993.1060206@mu.org> <537C63DF.1090402@mu.org> <8DDBACB5-749B-4660-B1DE-F2EE51033D96@cederstrand.dk> <537CD1EE.2000708@mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1878.2) Cc: FreeBSD Hackers , Royce Williams X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 20:40:16 -0000 Den 21/05/2014 kl. 18.18 skrev Alfred Perlstein : > That sounds reasonable. Is there a link to the specifics we can have? I'm surprised that I couldn't find anything written in the Developers' = Handbook or elsewhere. =46rom what I gather, it's along the lines of: * Don't break the API in the duration of a major release. Additional = features may be added in minor releases. * Mark an API for deprecation in the next major release, and remove it = in the next major release after that. * API changes should try to adhere to POLA. * The policy is not strict and may be violated for e.g. security = reasons. For convenience, a utility could announce the API version in the output = (something comparable to symbol versioning for shared libs), but a = simpler solution would simply require scripts to check which FreeBSD = release they are running on before making assumptions about the XML/JSON = output. Just like Python scripts that support different Python versions = must handle version differences manually. Erik=