dtody at nrao.edu
Thu Jul 2 11:19:39 PDT 2009
This is what I assumed the intent was as well. I think this should go
back to the D&S folks for clarification, with a recommendation that
this rule applies only to actual standards/RECs when substantial
changes occur in a new version. As Matthew says the specification
should be revised to clarify this.
On Thu, 2 Jul 2009, Alberto Micol wrote:
>> "The document now states that there is an integer increment in the version
>> number in the case where subsequent versions are not backward compatible.
>> So, for example, the progression of VOSpace 2.0 would actually proceed as:
>> VOSpace 2 (first WD)
>> VOSpace 3 (second WD)
>> VOSpace 4 (third WD)
>> VOSpace 5 (first PR)
>> VOSpace 6 (second PR)
>> VOSpace 7 (final PR)
>> VOSpace 8 (REC)
> My way to read that is that the integer increment happens
> for subsequent not backward compatible REC versions,
> not during the revision process WD->PR->REC.
> During the revision process only the date changes, not the version.
> That is, if a REC exists with version N.m, and a new version of that standard
> is being discussed, which will bring to an accepted new Exec version
> with version N, then such new WD must be numbered (N+1).0 -- otherwise
> N.(m+1) will suffice.
> The WD will then become PR without the need to change version number,
> but just only the date.
More information about the semantics