RE: [sarif] SARIF spec and schema versioning

["Larry Golding (Myriad Consulting Inc)" <v-lgold@microsoft.com>]

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

-- 
Paul Anderson, VP of Engineering, GrammaTech, Inc.
531 Esty St., Ithaca, NY 14850
Tel: +1 607 273-7340 x118; https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.grammatech.com&amp;data=02%7C01%7Cv-lgold%40microsoft.com%7C0401ea8f236746e4396e08d6255917d3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636737461922024215&amp;sdata=44WmCNdyW4kSIYHghVq7fg0hnAM8DKV%2BQD1DhHo1aMg%3D&amp;reserved=0


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.oasis-open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php&amp;data=02%7C01%7Cv-lgold%40microsoft.com%7C0401ea8f236746e4396e08d6255917d3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636737461922024215&amp;sdata=IxEQNv6sBpNvtZCE73UQPFPJruMiFZzkhBuZOxfr7%2FM%3D&amp;reserved=0