Versioning

[Doug Tody]

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.

 	- Doug


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 
> incompatible
> 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.
>
> Wrong?
>
> Alberto
>
>
>
>
>