Jonathan, thank you for your considered update. If we 'deprecate' a released version that has an error, presumably this just means it is no longer recommended for use? I assume data sets released with the flawed version shouldn't have to be re-released, if the flaw did not affect them.
And I'm assuming any time a new CF version is released, it is considered the recommended version, and all CF users are encouraged to use it as they write new data sets. But I don't know that I've read that anywhere. Martin, can you be specific about how reverting changes is less confusing when those changes are in provisional versions, than when they are in plain old released versions? Given your variants, perhaps we interpret 'provisional' differently? I understand it to be a released specification, usable but somehow not fully final/reliable. Perhaps your model would define it as an unreleased specification, versioned but not yet approved for use, which I agree is consistent with modern software practices. John On Feb 4, 2015, at 07:49, Schultz, Martin <[email protected]> wrote: > Dear Jonathan, all, > > we have had this discussion about provisional status earlier, and I > remember having received quite a bit of support for a proposal to have a > provisional status with a fixed lifetime. I still believe this would be > better than having to revert changes and create confusing new document > versions. I don't know what can be implemented (easily) in GitHub, but I > think there are various ways which don't differ too much in what they > accomplish, and one of them is hopefully both acceptable and easy to > implement: > Variant A) introduce a fixed publication cycle for the convention, e.g. every > 6 or 12 months with a "moratorium period" of, say 3 months, before > publication. This means that changes are only accepted up to 3 months prior > to the next publication, so there is a 3 months period for testing and > commenting/reverting changes. New changes would go into the next cycle only. > This scheme is adopted from software releases ("release candidate"). > Variant B) add date label to all changes and automatically accept them after > a fixed period (say 6 months) unless these changes were edited/reverted again > in the meantime (then, the date label should be changed to the last > modification). > Variant C) establish a "review panel" to go over modifications on a > semi-regular cycle and accept everything that has not been questioned > recently. This may sound more personnel-intensive than the other two options, > but I would guess that in reality the difference will be marginal if the > review panel is kept small. > > Best regards, > > Martin > > > In reply to: > Date: Wed, 4 Feb 2015 14:11:33 +0000 > From: Jonathan Gregory <[email protected]> > To: [email protected] > Subject: [CF-metadata] provisional status for changes to the > convention > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > Dear John > > Thanks for your posting. I have changed the subject so as not to mix it up > with the discussion about the format for maintaining the document. > > The rules expect that a test file is provided to accompany a change to the > conventions, but this has rarely or never been done in practice. We could > improve the procedure by insisting on this, when it's relevant. > > I agree with you that provisional status has a cost in complication and has > not given a benefit. The idea of provisional status is that it should be easy > to reverse provisional changes, I suppose, but we have not written down how > this would be done in practice, because we've not needed to. Therefore I would > be happy if we abolished provisional status. That means if a change is found > to be wrong, it would have to be reversed by opening a new ticket. > > Perhaps we could make a new procedure to help with this, should it ever be > needed. If a ticket is agreed to reverse a previous change which was found > to be wrong, it could mean that a new version of the convention is released > straight away, with the error corrected, so that it doesn't have to wait to > go live, and that the current and any other versions of the convention which > contain the erroneous change would then be deprecated. > > Best wishes > > Jonathan > > > > ------------------------------------------------------------------------------------------------ > ------------------------------------------------------------------------------------------------ > 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.-Ing. Wolfgang Marquardt (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
