From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <55130F34.10806@ericsson.com> Date: Wed, 25 Mar 2015 15:40:36 -0400 From: Simon Marchi MIME-Version: 1.0 References: <1932682628.103099.1427308743604.JavaMail.zimbra@efficios.com> <551307FE.8060507@ericsson.com> <369395798.103323.1427311320803.JavaMail.zimbra@efficios.com> In-Reply-To: <369395798.103323.1427311320803.JavaMail.zimbra@efficios.com> 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: Mathieu Desnoyers Cc: diamon-discuss@lists.linuxfoundation.org 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? Do the version numbers mean something? If introducing non backward compatible changes only bumps the minor version, what could ever bump the major? 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. Simon