> Instead of immediately releasing "1.7", there would be a, say six months period where we have "1.6" as official version and "1.7-beta" as test candidate for the next release
If we combine this with continually updated and published conventions documents then I think we're on to a winner.
To summarise so far, the workflow could be:
- Discussion takes place on a ticket/pull request.
- Pull request is merged in to the next development/alpha version. This automatically updates the published alpha version.
- At some point a new beta version is made and published. (This action only modifies relevant version numbers embedded in the document, e.g. in the title page.)
- In the unlikely case of a fix being required to a beta version then that will be done by merging directly to the beta version. The fix will also be applied to the current development version.
- Some number of months after a beta version is released (or last modified?) the beta status is removed.
Important points which would still need agreement:
- Where would modification discussion take place? (e.g. trac ticket/pull request)
- When are new beta versions are created? (e.g. time based/mailing list concensus/committee vote)
- When would a beta version be promoted to full status?
>From the perspective of a single document modification, it will first appear in the development version, then it will appear in a beta version, and finally the beta version will be promoted to a full release. For example, chapter 9 (discrete sampling geometries) would have been published as "1.6-alpha", then "1.6-beta", then "1.6".
Richard Hattersley
Expert Software Developer
Met Office FitzRoy Road Exeter Devon EX1 3PB United Kingdom
Tel: +44 (0)1392 885702
Email: richard.hattersley at metoffice.gov.uk Web: www.metoffice.gov.uk
-----Original Message-----
From: CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Schultz, Martin
Sent: 18 March 2014 14:03
To: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] Editing/publishing workflow (Hattersley, Richard)
> Message: 2
> Date: Tue, 18 Mar 2014 09:05:36 +0000
> From: "Hattersley, Richard" <richard.hattersley at metoffice.gov.uk>
> To: "Gregory, Jonathan" <j.m.gregory at reading.ac.uk>,
> "cf-metadata at cgd.ucar.edu" <cf-metadata at cgd.ucar.edu>
> Subject: Re: [CF-metadata] Editing/publishing workflow
> Message-ID:
> <21A2C87797FA6042B162A8A0A11A15DB06F60FCE at EXXCMPD1DAG2
> .cmpd1.metoffice.gov.uk>
>
> Content-Type: text/plain; charset="us-ascii"
>
> > I'd like to propose changing the rules. That's something the
> > conventions
> committee can agree, I believe. I would suggest the simplest
> possibility, if we wish to retain provisional status, is to specify a
> time. We could say that, after one year from acceptance or when the
> next version of the conventions document is published, whichever is later, a change becomes permanent.
> What do you think?
>
> The more I consider the concept of "provisional status" the more it
> concerns me. What does it actually mean for a netCDF file to use a
> particular "Conventions" attribute value? How can one tell what is
> still in provisional status? What version should data writers be
> using? I've checked back through 1.3, 1.4, 1.5, and 1.6 and they all
> still contain sections marked as provisional. Using the analogy to
> software versions that has been raised elsewhere, the CF convention
> versions are essentially pre-release versions, e.g. 1.6-beta, and are not suitable for production use.
>
> [...]
Dear all,
taking up Richard's comment: wouldn't it make most sense to change the release cycle as with any software product? Instead of immediately releasing "1.7", there would be a, say six months period where we have "1.6" as official version and "1.7-beta" as test candidate for the next release. This would allow everyone to develop, test and comment, while it remains fully clear which version is the latest operational one. CF checking tools could then even issue a warning if they find an outdated "*-beta" version in the Conventions attribute, and production datasets should simply refrain from using beta versions.
Best regards,
Martin
===================
PD Dr. Martin G. Schultz
IEK-8, Forschungszentrum J?lich
D-52425 J?lich
Ph: +49 2461 61 2831
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Thu Mar 20 2014 - 08:22:48 GMT
