> Namely, if we agree what we want to do in CF-2.0, including backward-incompatible changes, does that mean CF-1 will stop at CF-1.7 (the version currently being drafted)?
Perhaps that is a decision that can be made at the appropriate time, namely: after CF-2.0 is well on its way toward completion, and someone thinks there is a need to advance 1.7? (Or whatever version we are on when CF-2.0 is released?)
I could imagine that small or important changes might be easily made to the 1.7 line, even while 2.0 is approved, IF it turns out there are incompatibilities that will take time to move past. But we won't know that until we know how different 2.0 is from 1.7, and how easy/appropriate the transition will be for everyone.
John
On Oct 7, 2014, at 07:36, Jonathan Gregory <j.m.gregory at reading.ac.uk> wrote:
> Dear John
>
> Thanks for the charter and rules. This looks fine to me. Thanks in particular
> for accommodating my concerns.
>
> I do have one more point, which doesn't affect the discussion, but will be
> relevant later. Namely, if we agree what we want to do in CF-2.0, including
> backward-incompatible changes, does that mean CF-1 will stop at CF-1.7 (the
> version currently being drafted)? I think Yes. It would be too complicated
> to have more than one current version. We can barely manage to maintain even
> one thread of development.
>
> Best wishes
>
> Jonathan
>
> ----- Forwarded message from John Caron <caron at ucar.edu> -----
>
>> Date: Mon, 6 Oct 2014 17:19:45 -0600
>> Subject: CF-2 discussion almost ready
>> From: John Caron <caron at ucar.edu>
>> To: "cf-metadata at lists.llnl.gov" <cf-metadata at lists.llnl.gov>
>>
>> Thanks to John and Chris for summarizing. I think we are almost ready to
>> go. Heres my summary:
>>
>>
>> Charter/Scope
>>
>> (1) What use-cases cannot be met with the classic model, or could be met
>> much more easily with the extended model?
>>
>> (2) Possible things to deprecate (because there is a better way to do it)
>>
>> (3) Backwards compatibility is desirable, but not required if there is a
>> substantial advantage in simplicity and clarity. So respect precedent and
>> dont constrain important innovation. There has to be a strong advantage for
>> making incompatible changes.
>>
>> (4) If we introduce a new way to do something, we should carefully consider
>> removing the old way, because it is easier for users of the convention if
>> there is only one way to do something.
>>
>>
>> Process:
>>
>> We will try out using github for the discussion and the "discussion
>> summary" document.
>>
>> 1) We will use the CF github account if possible.
>>
>> 2) We will create a new repo under https://github.com/cf-convention, say,
>> https://github.com/cf-convention/CF-2.
>>
>> 3) We will use the "Issues" feature to discuss. Essentially this allows
>> threaded discussion, and new issues are created as needed to keep things
>> on-topic.
>>
>> 4) We will use the wiki to create a "discussion summary" document. It looks
>> adequate in that we can create various pages and link them together. It
>> will be a collaborative document where anyone can write (add your name to
>> your edits perhaps?) At some point we will probably transition to a
>> collection of documents in the repo.
>>
>> Anyway, we can get started and refine this set of guidelines as we go.
>>
>> Questions:
>>
>> - Who has admin rights to the CF github account?
>> - How do people get permission to write?
>> - Any other ground rules needed?
>> - Any changes to the above?
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Tue Oct 07 2014 - 10:33:09 BST
