OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sarif message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [sarif] SARIF spec and schema versioning

Those are good ideas. I incorporated them into the provisional draft, and updated the HTML version to match.


-----Original Message-----
From: James Kupsch <kupsch@cs.wisc.edu> 
Sent: Monday, October 1, 2018 7:32 AM
To: Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com>; Paul Anderson <paul@grammatech.com>; sarif@lists.oasis-open.org
Subject: Re: [sarif] SARIF spec and schema versioning

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.


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]