From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 25 Mar 2015 21:00:43 +0000 (UTC) From: Mathieu Desnoyers Message-ID: <939295554.103805.1427317243385.JavaMail.zimbra@efficios.com> In-Reply-To: <987784607.103695.1427316285128.JavaMail.zimbra@efficios.com> References: <1932682628.103099.1427308743604.JavaMail.zimbra@efficios.com> <551307FE.8060507@ericsson.com> <369395798.103323.1427311320803.JavaMail.zimbra@efficios.com> <55130F34.10806@ericsson.com> <987784607.103695.1427316285128.JavaMail.zimbra@efficios.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 , Philippe Proulx Cc: diamon-discuss@lists.linuxfoundation.org Philippe might want to chime in. ----- Original Message ----- > ----- 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 > _______________________________________________ > diamon-discuss mailing list > diamon-discuss@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/diamon-discuss > -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com