Re: [sarif] SARIF spec and schema versioning

[James Kupsch <kupsch@cs.wisc.edu>]

I don't think 2.0.0 needs to replaced everywhere, but I think that the 
version number should appear at least once in the word document, so 
someone who has a copy (outside of the git repository) can identify the 
version.  Perhaps the second line in the document:

   Committee Specification Draft 01

is the right place and should become (the Draft is 02?):

   Committee Specification Draft 02 (2.0.0-beta.2018.09.26)

The third line could also be updated with the revision's date

   26 September 2018

Also it would good to add a note that remains in place until the 
specification if finalized in the version description that states 
throughout the document the version value "2.0.0" is used, but producers 
SHOULD use the version value "2.0.0-beta.YYYY.MM.DD" (found in the 
second line of this document) in place of "2.0.0" to denote the specific 
draft revision of the SARIF file.

Jim




On 09/28/2018 06:51 PM, Larry Golding (Myriad Consulting Inc) wrote:
> The only changes from what Jim proposed are:
> 
> 1. I will not go through the spec after each TC meeting, changing all occurrences of "2.0.0" to "2.0.0-beta.2018.09.26" or whatever. The spec will still say that the only valid value for version is "2.0.0", but the schema will say the right number.
> 
> 2. Michael, there's an additional Step 7 where you publish the new schema to schemastore.org.
> 
> Thanks,
> Larry
> 
> -----Original Message-----
> From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org> On Behalf Of Paul Anderson
> Sent: Friday, September 28, 2018 8:43 AM
> To: James Kupsch <kupsch@cs.wisc.edu>; sarif@lists.oasis-open.org
> Subject: Re: [sarif] SARIF spec and schema versioning
> 
> Jim:
> 
> I've been running into the same issue myself with both exporting and importing, so thank you for proposing we bring order to this.
> 
> 
> On 9/26/2018 3:52 PM, James Kupsch wrote:
>> After the meeting today, Michael, Larry and I discussed how producers
>> can declare and consumers identify the changing draft of the SARIF
>> specification used to construct a SARIF file.  Right now all SARIF files
>> identify themselves as 2.0.0 (which clearly they are not).
>>
>> Our proposal is the following unless there are objections:
>>
>> 1) The SARIF draft version will be of the form 2.0.0-beta.YYYY.MM.DD
>> where YYYY, MM and DD are numeric values indicating the draft revision
>> of SARIF.  This is valid semantic version that is before 2.0.0.
> If I understand correctly, you are proposing that this is the form of
> the string that will show up in the "version" property of the top-level
> object. Is that right? Is this format then part of the standard?
>> 2) Upon final specification approval the version will change to "2.0.0".
>>
>> 3) We do not believe that we need to support current producers that have
>> used "2.0.0" for a version.
>>
>> 4) Producers SHALL use the draft version to indicate the version they
>> produce.
>>
>> 5) The Provisional draft and schema will be updated to reflect this.  I
>> will leave this up to Larry.
>>
>> 6) The git repository will be tagged with the draft version so you can
>> retrieve the Provisional Draft and schema after committing the
>> Provisional draft document and JSON schema with approved changes from
>> the TC.
>>
>>
>> Let us know if you have any comments, and Michael and Larry let me know
>> if forgot anything or got anything wrong.
> I'm coordinating some work on producers; I decided that we would all
> work on the same draft version, and that it would be one of the first
> versions that to come right after the TC had accepted the proposed
> changes for the externalized files as that appeared to be the most
> pervasive change that was pending. I was wondering if we should have a
> new Committee Specification Draft, and for that to be the one we work
> with. It would be more stable than an arbitrarily chosen date. Does that
> make sense? Is that what CSDs are intended for?
> 
> -Paul
>