Re: [diamon-discuss] Common Trace Format 1.9 planning

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

----- 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