Final changes for 1.4.1 release, including version updates.

I used #327 as an example, and followed the instructions mentioned in #327.

Signed-off-by: smolkaj <[email protected]>

bazel/example/WORKSPACE.bazel

@@ -1,29 +1,19 @@
 load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository")
 load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
 
+# In your own project, you will likely want to use `http_archive` instead
+# of `local_repository` to load p4runtime.
 local_repository(
     name = "com_github_p4lang_p4runtime",
     path = "../../proto",
 )
-
-# In your own project, you will likely want to use `http_archive` or
-# `git_repository` instead of `local_repository` to load p4runtime.
-
 # http_archive(
 #     name = "com_github_p4lang_p4runtime",
-#     urls = ["https://github.com/p4lang/p4runtime/archive/v1.4.0.tar.gz"],
-#     strip_prefix = "p4runtime-1.4.0/proto",
+#     urls = ["https://github.com/p4lang/p4runtime/archive/v1.4.1.tar.gz"],
+#     strip_prefix = "p4runtime-1.4.1/proto",
 #     # sha256 = "<insert hash value here>",
 # )
 
-# git_repository(
-#   name = "com_github_p4lang_p4runtime",
-#   remote = "https://github.com/p4lang/p4runtime.git",
-#   # strip_prefix = "proto",  # https://github.com/bazelbuild/bazel/issues/10062
-#   patch_cmds = ["mv proto/* ."],  # Workaround since strip_prefix is broken.
-#   tag = "v1.4.0",
-# )
-
 load("@com_github_p4lang_p4runtime//:p4runtime_deps.bzl", "p4runtime_deps")
 
 p4runtime_deps()

docs/v1/P4Runtime-Spec.mdk

@@ -1,5 +1,5 @@
 Title : P4Runtime Specification
-Title Note: version 1.4.0-dev
+Title Note: version 1.4.1
 Title Footer: &date;
 Author: The P4.org API Working Group
 Heading depth: 5

docs/v1/guidance-for-generating-p4info.md

@@ -38,7 +38,7 @@ representing the name of the library, its major version, etc.
 
 ## Handling P4_16 `type` and the `p4runtime_translation` annotation
 
-The P4Runtime v1.3 specification restricts the types that it supports
+The P4Runtime v1.4 specification restricts the types that it supports
 for the following kinds of things:
 
 + table search key fields, defined in the P4Info message in a
@@ -54,13 +54,13 @@ for the following kinds of things:
 
 Later in this section, we will use the term "constrained value" for
 brevity, instead of repeating all of the kinds of objects listed
-above.  For such values, the P4Runtime specification v1.3 supports all
+above.  For such values, the P4Runtime specification v1.4 supports all
 of the following types, but currently no others:
 
 + `bit<W>`
 + an `enum` with an underlying type of `bit<W>`, also called a
   serializable `enum` (TBD whether all of the pieces needed to make
-  this work are actually supported for P4Runtime 1.3)
+  this work are actually supported for P4Runtime 1.4)
 + a `typedef` or `type` name that, when "followed back" to the lowest
   base type, is one of the above.  (As of the P4_16 language
   specification version 1.2.1, it is not required to support a `type`
@@ -100,7 +100,7 @@ type_list(x) {
 Note that `type_list(x)` always starts with zero or more `type` names,
 and always ends with one type that is neither a `type` nor `typedef`
 name, e.g. `bit<W>`, a header type, struct type, etc.  It never
-contains the name of a type declared using `typedef`.  P4Runtime v1.3
+contains the name of a type declared using `typedef`.  P4Runtime v1.4
 only supports `p4runtime_translation` annotations on `type`
 definitions.  If any such annotations occur on a `typedef` definition,
 they should be ignored.
@@ -111,7 +111,7 @@ of type names.  In order to create such a cycle, the first `type` or
 type name, and this is not allowed.
 
 If the last type is not `bit<W>` or `enum bit<W>`, that is an error
-for P4Runtime v1.3.  The "base" type must always be one of those for
+for P4Runtime v1.4.  The "base" type must always be one of those for
 every constrained value.