In an earlier, and different, thread Rich Signell mentioned the Semantic
Versioning concept of x.y.z notation, meaning MAJOR.MINOR.PATCH. See
http://semver.org/ and in particular items 6-8. I agree with Rich in that
semantic versioning is a good approach and something CF should consider
explicitly adopting.
If we do adopt it, then by considering a 2.0.0 (note the extra zero)
development effort, we are admitting backwards incompatibility into the
discussion. I personally don't believe we can be infinitely backwards
compatible but I do subscribe to the somewhat conservative use case driven
approach toward evolution. If CF is unwilling to admit backwards
incompatibilty into the discussion then we're really talking about 1.8.z
not 2.0.0 requirements.
NOTE I don't think that embracing the full feature set of netCDF4/HDF5
necessarily implies we are allowing the existence of technology to drive
the evolution of the standard. We can still have a use case driven plan to
force us to decide between 1.8.z and 2.0.0.
I think Heiko's suggestion of strict vs. transitional subsets is
interesting, even if it complicates the management of the standard
artifacts. I *think* this idea is supported by semver, in particular see
item 11, but I'd like someone more seasoned than me to verify that
statement.
If we fully embrace the semantic versioning ideas, then it's worth further
exploring the proposal to move to the github model of fork/branch/pull
request/merge to support management of collaborations, branches, and
explorations. Git-flow ( eg. [1]
<
https://www.atlassian.com/git/tutorials/comparing-workflows/centralized-workflow>
and [2] <
http://nvie.com/posts/a-successful-git-branching-model/> ) allows
for the selective inclusion of branches into the trunk. The existence of
an explorative branch doesn't necessarily imply that it will be merged into
the trunk, but git does support the management of the branch in a
consistent way. It get's hard to adhere to semver item 3 without a mature
set of tools like git.
Further, this model can support the inclusion of some of the "workgroups"
into the CF standard more explicitly. For example, I've never fully
understood the relationship of groups like cf-satellite or cf-radials to
the core CF standard. It seems to me that they are somewhat orphans.
I look forward to the discussion!
Derrick
On Mon, Sep 22, 2014 at 3:51 AM, Heiko Klein <Heiko.Klein at met.no> wrote:
> Dear Jonathan,
>
> removal/backward incompatibility is a difficult issue, and having several
> ways to do things just because of backward compatibility will make CF hard
> to understand. It is not only new features in CF which introduces too many
> ways to do things, also the existing document has plenty of examples, e.g.
> at least 6 different ways to describe a latitude axis (and that even
> without counting standard_name and axis attributes).
>
> While I think maintaining two sets of CF (1.x, 2.x) will be very hard, I
> think acceptance of a CF-2.x series can only be achieved with enough
> compatibility.
>
> I liked the way of the HTML-4 group to allow for a "transitional" and a
> "strict" set of features. This should make it easy to adapt existing
> datasets to CF-2-transitional, while new datasets should be tested against
> a 'strict' CF-checker.
>
>
> I agree with your comments about the way of discussion, history and open
> communications is import.
>
>
> Best regards,
>
> Heiko
>
>
>
>
> On 2014-09-19 16:11, Jonathan Gregory wrote:
>
>> Dear John
>>
>> So I propose we have a 3 month discussion period where we clarify what
>>> the
>>> issues are and possible improvements or changes. We wont try too hard
>>> during that period to create final wording, and divergences of opinion
>>> will
>>> be recorded rather than resolved. After that we will have another 3 month
>>> period where we try to write a document and make decisions.
>>>
>>
>> It is good to have a timescale for discussion. That might not be long
>> enough,
>> but let's see!
>>
>> I propose these ground-rules for what we discuss:
>>> 1. Changes needed to use the extended model.
>>> 2. Possible things to deprecate or remove.
>>> 3. Possible new functionality esp if it comes from using the extended
>>> model.
>>> 4. 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.
>>>
>>
>> By "extended model" do you mean the netCDF4 model? I don't think we should
>> begin with an *aim* to use the netCDF4 model. The question is, what do we
>> need
>> to do which we *can't* do in the classic model, or could be done much more
>> easily in the extended model than in the classic model? That is, changes
>> to CF
>> should be driven by use-cases, not technology. So I would combine 3 and 1
>> as
>>
>> (1) What use-cases cannot be met with the classic model, or could be met
>> much
>> more easily with the extended model?
>>
>> Since "remove" implies "backward-incompatible", I would put (2) as
>>
>> (2) Possible things to deprecate (because there is a better way to do it
>> - I assume - are there other reasons?)
>>
>> Then
>>
>> (3) Possible things to remove, or to require if they are currently only
>> optional. Such changes mean backwards-incompatibility. I think that the
>> default should be backwards compatibility. There has to be a strong
>> advantage
>> for making incompatible changes. (NB I am not saying that backward
>> incompatibility is out of the question!)
>>
>> I do not think we should introduce a new way of doing something because
>> it might look nicer, unless it is clearly functionally much better than
>> the
>> existing way. Also, 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.
>>
>> Whatever way the discussion is done, I think it's important that
>> - it should be public to read and contribute to
>> - it should have a history, so we can all see what we and others said
>> earlier.
>>
>> Best wishes and thanks
>>
>> Jonathan
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>>
> --
> Dr. Heiko Klein Tel. + 47 22 96 32 58
> Development Section / IT Department Fax. + 47 22 69 63 55
> Norwegian Meteorological Institute http://www.met.no
> P.O. Box 43 Blindern 0313 Oslo NORWAY
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
Derrick Snowden
System Architect and Acting Chief, Operations and Communications Division
US IOOS <http://www.ioos.noaa.gov>
1100 Wayne Ave, Suite 1225
Silver Spring, MD 20912
+1 301 427 2464 (o), +1 301 427 2073 (f)
Find us on Facebook <http://www.facebook.com/usioosgov>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20140922/dfba6261/attachment.html>
Received on Mon Sep 22 2014 - 20:22:04 BST
