From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 25 Mar 2015 20:44:45 +0000 (UTC) From: Mathieu Desnoyers Message-ID: <987784607.103695.1427316285128.JavaMail.zimbra@efficios.com> In-Reply-To: <55130F34.10806@ericsson.com> References: <1932682628.103099.1427308743604.JavaMail.zimbra@efficios.com> <551307FE.8060507@ericsson.com> <369395798.103323.1427311320803.JavaMail.zimbra@efficios.com> <55130F34.10806@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [diamon-discuss] Common Trace Format 1.9 planning List-Id: DiaMon diagnostic and monitoring workgroup general discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Simon Marchi Cc: diamon-discuss@lists.linuxfoundation.org ----- Original Message ----- > On 15-03-25 03:22 PM, Mathieu Desnoyers wrote: > > > This is great, so v1.9 is a superset of 1.8. > > > > No. A superset would be a completely backward compatible 1.9. > > This is not the case here. We plan to do incompatible changes > > within 1.9, hence the 1.8 and 1.9 parsers needed. Since the > > version is self-described, it should not be an issue to detect > > the CTF version from the trace metadata. > > From what I understand, it means that a reader for 1.9 won't be able to read > a 1.8 trace, is that right? Yes, we plan to add incompatible grammar changes. This might have to be versioned as 2.0 then. However, we can have side-by-side implementations of CTF 1.8 and 2.0 readers within a trace reading lib, and therefore distinguish between those, and use the proper CTF reader implementation. > > Do the version numbers mean something? If introducing non backward compatible > changes only bumps the minor version, what could ever bump the major? Good question! In this case, we might be talking about a CTF 2.0 then, since we are planning non-compatible changes. > > If they don't have one already, this could be an opportunity to give a > meaning > to the numbers. The major could be for breaking backward compatibility, while > the minor could be for backward-compatible changes. It would mean that a > reader > for x.y should be able to read any x.z trace, where z <= y. In other words, > the > x.y format would be a superset of x.z (I think?). Much like semver.org, but > without the PATCH level. Yes, I think it's a good approach. We have been hesitating between moving from CTF 1.8 to either 1.9 or 2.0. Here are the upsides/downsides of each approach: * 1.8 to 1.9: + Compatibility: New CTF 1.9 readers would be able to read CTF 1.8 traces, - Incompatibility: CTF 1.8 readers would not be able to read CTF 1.9 traces, - Complexity: The CTF 1.9 specification would need to be an exact subset of 1.8, which means a more complex spec, grammar, and implementations, * 1.8 to 2.0: + Compability: Since we're keeping the version headers, a trace reader can implement parsers for both CTF 1.8 and 2.0, and read both trace formats without requiring user interaction, - Incompatibility: CTF 1.8 readers would not be able to read CTF 2.0 traces, + Simplicity: New CTF 2.0 readers would be simpler, since they would not need to read CTF 1.8 traces, Since the user-visible impacts of bumping from 1.8 to 1.9 or from 1.8 to 2.0 appear to be the same for existing implementations of the spec, I am really tempted to bump to 2.0 at this stage. Already having the version number in the header makes the transition so much easier to manage. Thoughts ? Thanks! Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com