Versioning

[Doug Tody]

Only changes which are not backwards compatible should require an increment
to the major version number.  In particular, if new stuff is added that
does not change old stuff, that is a minor revision.

Note that versioning and version checking is already codified in the
DAL standards, based upon the documentation version standard we have
had for the past few years.  If the server and client disagree on the
major version number that is an error condition.  What we have below
is still consistent with this practice.

 	- Doug


On Thu, 2 Jul 2009, Dave Morris wrote:

> I agree with Doug and Guy.
>
> Doug Tody wrote:
>
>>  If this were true I agree it would be crazy.  But is a WD or PR a
>>  "standard"?  I should think this would only apply to established
>>  standards that are already deployed.  That is, to recommendations.
>
> If the integer rule only applied to something that has been accepted as a 
> recommendation.
>
> VOSpace 2.0-yyymmdd (first WD)
> VOSpace 2.0-yyymmdd (second WD)
> VOSpace 2.0-yyymmdd (third WD)
> VOSpace 2.0-yyymmdd (first PR)
> VOSpace 2.0-yyymmdd (second PR)
> VOSpace 2.0-yyymmdd (final PR)
> VOSpace 2.0 (REC)
>
> VOSpace 2.1-yyymmdd (first WD) (minor text changes only)
> VOSpace 2.1-yyymmdd (final PR) (minor text changes only)
> VOSpace 2.1 (REC)
>
> VOSpace 3.0-yyymmdd (first WD) (changes to service behavior or xml schema)
> ....
>
> I'd be ok with that.
> I don't understand why we need it, but it would be ok.
>
> To qualify as a minor version number the change would have to be pretty 
> small, possibly spelling corrections in the document. Anything else would 
> mean at least some changes to the client or server code, so would 
> automatically get a major version number.
>
> Dave
>
>
>