Close some rel management issues, update Versioning to latest behavior (

onnx#242)

RELEASE-MANAGEMENT.md

@@ -2,22 +2,14 @@
 
 This describes the process by which versions of ONNX are officially released to the public.
 
-ISSUE: How do we manage IR and operator version #'s for a given release/pre-release both pre-declaration and post-declaration?
-
-ISSUE: How do we use experimental on operators (or potentially IR features) for a given release/pre-release?
-
-ISSUE: How do we communicate schedules and exit criteria for a given pre-release/release?
-
-ISSUE: How do we stablize one pre-release/release while we are working on subsequent ones?
+Releases
+--------
 
-ISSUE: which files should be included? Probably an archive of all files (minus tests if they get large). How about protoc targets?
+Releases are versioned according to [docs/Versioning.md](docs/Versioning.md). This describes IR and operator versioning policies, as well as propose how models themselves should be versioned.
 
-### Fodder from versioning.md that belongs here somewhere.
-Per the rules of SemVer 2.0, during the initial development of ONNX:
-* We use a MAJOR version of 0 for both the IR version and operator version.
-* We will only increment the MINOR version in the face of either a breaking change as defined in this specification or the need to stabilize a version for specific engineering purposes.
+The GitHub repo for ONNX provides release branches where the project is stabilized as per the process described here. Release notes are used to communicate the stability and status of a release. The master branch will be used to continue work for subsequent releases.
 
-Once we declare a stable/released version of ONNX (e.g., we hit 1.0.0), we will adhere to the standard SemVer rules for versioning.
+Major, minor and patch releases will have branch names and version numbers reflecting the nature of the change as per semantic versioning definitions.
 
 Workflow
 --------

docs/Versioning.md

@@ -34,25 +34,11 @@ The ONNX versioning principles are based on [Postel's law](https://en.wikipedia.
 The operational rules for how the ONNX project is managed are documented at [here](../RELEASE-MANAGEMENT.md).
 
 ### Serializing SemVer version numbers in protobuf
-
 For efficiency, ONNX serializes the MAJOR, MINOR, and PATCH values as a bit-packed 32-bit integer; the most siginificant byte is the MAJOR component, the second most significant byte is the MINOR component, the least significant two bytes are the PATCH component.
 
 For example, 1.2.345 is represented as 0x01020159.
 
-The prerelease and build metadata are stored as distinct string fields. For example:
-
-    optional int32 model_version = x;
-    optional string model_prerelease = y;
-    optional string model_build_metadata = z;
-
-The SemVer value 1.2.345-alpha.1+mips.dbg would be represented as:
-
-    model_version: 0x01020159,
-    model_prerelease: "alpha.1",
-    model_build_metadata: "mips.dbg"
-
-An absent prerelease or build_metadata field imply no corresponding component in the SemVer value.
-
+The prerelease and build metadata aren't stored in the model.
 
 ## IR versioning
 
@@ -88,11 +74,10 @@ ONNX models declare which operator sets they require as a list of two part opera
 ONNX specification. The union of the operator sets specified by a given model MUST have have have a compatible operator declaration for each node in the model's graph.  
 
 
-How nodes bind to operator declarations is strictly defined and are designed to increase model compatibilitey across ONNX implementations (appealing to the conservative clause of the robustnes principle). 
+How nodes bind to operator declarations is strictly defined and are designed to increase model compatibility across ONNX implementations (appealing to the conservative clause of the robustnes principle). 
 
-How ONNX implementations bind an operator declaration to specific implementation is outside the scope
-of this specification.  Implementations of ONNX MAY elect 
-to introduce more sophisticated operator declaration/implementation binding modes to appeal to the liberal clause of the robustness principle. 
+How ONNX implementations bind an operator declaration to specific implementation is outside the scope of this specification.
+Implementations of ONNX MAY elect to introduce more sophisticated operator declaration/implementation binding modes to appeal to the liberal clause of the robustness principle.
 
 ## Model versioning
 
@@ -127,4 +112,3 @@ ISSUE: what's our policy when a model takes a dependency on new `IR_VERSION` cha
 
 Assuming that there are no breaking changes to the signature of the model's graph or any operator dependencies, the shape and contents of the graph can change freely provided there are no semantic changes to the model. However, changes to the shape and contents of the graph can impact model accuracy and/or model performance.
 
-ISSUE: what's our policy for accuracy or perf changes?