> 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: [email protected] Web: www.metoffice.gov.uk -----Original Message----- From: CF-metadata [mailto:[email protected]] On Behalf Of Schultz, Martin Sent: 18 March 2014 14:03 To: [email protected] Subject: Re: [CF-metadata] Editing/publishing workflow (Hattersley, Richard) > Message: 2 > Date: Tue, 18 Mar 2014 09:05:36 +0000 > From: "Hattersley, Richard" <[email protected]> > To: "Gregory, Jonathan" <[email protected]>, > "[email protected]" <[email protected]> > Subject: Re: [CF-metadata] Editing/publishing workflow > Message-ID: > <21A2C87797FA6042B162A8A0A11A15DB06F60FCE@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 [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
