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

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
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/diamon-discuss
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com