Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Wed, 26 August 2020 19:55 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF083A09F9 for <netmod@ietfa.amsl.com>; Wed, 26 Aug 2020 12:55:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isGIMtk_Omtl for <netmod@ietfa.amsl.com>; Wed, 26 Aug 2020 12:55:31 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 134BE3A09F8 for <netmod@ietf.org>; Wed, 26 Aug 2020 12:55:30 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id D0A6F35E; Wed, 26 Aug 2020 21:55:28 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id qu3QHIBXoVt2; Wed, 26 Aug 2020 21:55:28 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 26 Aug 2020 21:55:28 +0200 (CEST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6D70520156; Wed, 26 Aug 2020 21:55:28 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id JkQ21srFhiE7; Wed, 26 Aug 2020 21:55:28 +0200 (CEST)
Received: from localhost (anna.jacobs.jacobs-university.de [10.50.218.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by hermes.jacobs-university.de (Postfix) with ESMTPS id BE35F20154; Wed, 26 Aug 2020 21:55:27 +0200 (CEST)
Date: Wed, 26 Aug 2020 21:55:27 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "Joe Clarke (jclarke)" <jclarke@cisco.com>
Cc: Ladislav Lhotka <ladislav.lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <20200826195527.dfl45srxuqprmhlm@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: "Joe Clarke (jclarke)" <jclarke@cisco.com>, Ladislav Lhotka <ladislav.lhotka@nic.cz>, "netmod@ietf.org" <netmod@ietf.org>
References: <5CF24083-4126-4BE0-93F1-9A36F6DE9296@cisco.com> <20200811.164556.608015447238311339.id@4668.se> <A634B3C1-9F19-4A44-9479-56EC986DA1D8@cisco.com> <878sekb885.fsf@nic.cz> <11245BD3-6E79-4F02-9962-53BE87264460@cisco.com> <acfe1b95-e0f3-0b7e-2635-9582eb11b4e6@nic.cz> <20200813102302.xwowkncgur4s7yuc@anna.jacobs.jacobs-university.de> <E8EFFABC-B60F-438C-B9AB-3204A834DC9D@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <E8EFFABC-B60F-438C-B9AB-3204A834DC9D@cisco.com>
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/we3iUZu4xTw6F93B2udm4l5lJJs>
Subject: Re: [netmod] IETF 108: Summary of insignificant whitespace changes and versioning
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Aug 2020 19:55:34 -0000

On Wed, Aug 26, 2020 at 05:43:27PM +0000, Joe Clarke (jclarke) wrote:
> 
> 
> > On Aug 13, 2020, at 06:23, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > 
> > On Thu, Aug 13, 2020 at 11:37:18AM +0200, Ladislav Lhotka wrote:
> >> 
> >> 
> >> $ pyang -f yin ietf-inet-types.yang | xmllint --c14n - | sha256sum
> >> 8d1ca8f30566ce8cbeffa095e20642f8f6e9f3a724286be4ead863b4467dc40b  -
> >> 
> >> might be a very good start. It is certainly much more robust than
> >> relying on a simple checksum of the YANG module text.
> > 
> > This work started with the need for _semantic_ version numbers and now
> > we are down to hashes of modules? Do we still have a clear idea which
> > problem we are solving?
> 
> Sorry for the delay.  I was traveling and then trying to get caught back up.  Yes, things got off track a bit here.
> 
> > 
> > - Sane development environments use version control systems, we should
> >  in my view not attempt to go there. We should assume that people
> >  developing YANG modules use version control systems to track
> >  changes.
> 
> Agreed.  And through that development, we are not trying to impose any versioning up to the point that a module would be published (e.g., in a draft where it might be implemented).  Certainly, people could also pull and implement any arbitrary revision from a VCS, but we haven’t created any text to cover that (nor do I think we want to impose that each commit revs some version in the module itself).
> 
> > 
> > - There apparently is a need for a packaging system that can express
> >  which combinations of YANG module version are known to work
> >  together.
> > 
> > The YANG versioning work was driven (I think) by the desire to
> > support non-backwards compatible changes (section 4 of
> > draft-ietf-netmod-yang-versioning-reqs-03). Why do we end up
> > discussing how to calculate hashes or the impact of whitespace
> > changes? Whitespace and layout changes are backwards compatible,
> > even today's YANG versioning rules handle them well.
> 
> The intent, at least for the whitespace changes was at a module release time to indicate what constitutes a version bump.  But the question could likely be rephrased.  Would one change the _revision_ of a module for any of the changes mentioned thus far?  And if a new revision is created, and semantic versioning is used a revision-label scheme, then that revision should have a new version label.  At least this was the opinion of the contributors in the regular weekly calls.
>

The goal of the effort was to allow for non-backwards compatible
changes. Backwards compatible changes already work today (and white
space changes are obviously backwards compatible). If you want to
_publish_ a module with just whitespace changes, it is defined how to
do this.

I would find it way more important to mark which specific definitions
had backwards incompatible changes (plus perhaps hints how to deal
with them) instead of sticking a label on an entire module and then to
let others figure out what this label actually means for them (and
ultimately it is then the package maintainer's job to dig out which
revision sets can meaningfully work together).

If I make a non-backwards compatible change to the definition of
object-identifier in ietf-yang-types, then likely >98% of the modules
importing ietf-yang-types will not at all be affected by this. Still I
would have to declare a major version change triggering a lot of 'uhm,
ehm, what'. Expressing incompatibilities at the module level is pretty
arbitrary since the way definitions are organized into modules is
already somewhat arbitrary.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>