Managing-Releases.md

@@ -4,6 +4,7 @@ title: Managing Releases
 
 
 
+
 # Overview
 There are many ways to manage software releases with Git.  Git does not require any particular method to denote a release, though the most common method is a Git tag, and this is recommended.  Further, Git Dev Platforms often provide a platform specific release feature as well.  Git does not require any particular versioning scheme, but Semantic Versioning is a popular choice and recommended.  The contents of release notes is also subjective, although at a minimum a Git diff between previous release tag and new release tag is recommended.
 
@@ -15,10 +16,10 @@ Developer Platforms such as GitLab and GitHub provide a `releases` feature, that
 # Release Triggers
 There are two common ways to trigger a new release workflow: On push of a VERSION file change, or on push of a Git tag change.  We've landed on the VERSION file approach as explained below.
 
-It's generally useful for software to be able to answer the question at runtime of what version it is.  Further, many build tools such as Java Gradle and Python buildtools expect a version specifier in their configuration.  Therefore, one major concern with release triggering is how to synchronize the version specifier used by the software and software build tools with the version specifier implied by a Git tag.
+It's generally useful for software to be able to answer the question at runtime of what version it is.  Further, many build tools such as Java Gradle and Python build tools expect a version specifier in their configuration.  Therefore, one major concern with release triggering is how to synchronize the version specifier used by the software and software build tools with the version specifier implied by a Git tag.
 
 ## VERSION file
-In this approach a new release is created when a VERSION file is pushed to the main branch at the origin server (Dev Platform).  This has the advantage of the tagged version of the software already containing a file with a matching version number.   Running software can be configured to read this VERSION, and the build tools can as well.  This has the advantage of being language agnostic as well as instead of figuring out how to insert the version into the build tools in a language specific way, the onus is reversed, and build tools can use their language specific mechanisms to read from a standard VERSION file.
+In this approach a new release is created when a VERSION file is pushed to the main branch at the origin server (Dev Platform).  This has the advantage of the tagged version of the software already containing a file with a matching version number.   Running software can be configured to read this VERSION, and the build tools can as well.  This has the advantage of being language agnostic, and instead of figuring out how to insert the version into the build tools in a language specific way, the onus is reversed, and build tools can use their language specific mechanisms to read from a standard VERSION file.
 
 ## Tag Push
 In this approach users push a new tag to trigger a release.  However, since build tools need the version number readily available you must provide it somehow.  Here are two common options: