Remove changelog requirement for release. (#100)

Since github manages changelogs now, there is no need for a manual changelog.
Other repositories have also shifted to this technique.

Signed-off-by: David Enyeart <[email protected]>

CHANGELOG.md

@@ -1,3 +1,11 @@
+# fabric-contract-api-go Changelog
+
+fabric-contract-api-go [releases](https://github.com/hyperledger/fabric-contract-api-go/releases) each have a changelog maintained by GitHub.
+
+# Early fabric-contract-api-go release Changelogs
+
+Early fabric-contract-api-go releases prior to v1.2.1 copied commit history into the changelog file below.
+
 ## v1.2.0
 Fri 23 Sep 2022 14:22:09 BST
 
@@ -61,4 +69,4 @@ Wed  5 Feb 2020 16:17:56 GMT
 * [04f3921](https://github.com/hyperledger/fabric-contract-api-go/commit/04f3921) Add changelog, script and check (#5)
 * [0e2d581](https://github.com/hyperledger/fabric-contract-api-go/commit/0e2d581) Make unit tests verbose and fix godog path (#4)
 * [a545e98](https://github.com/hyperledger/fabric-contract-api-go/commit/a545e98) Fix gofmt issues (#3)
-* [f9df77e](https://github.com/hyperledger/fabric-contract-api-go/commit/f9df77e) Initial commit
+* [f9df77e](https://github.com/hyperledger/fabric-contract-api-go/commit/f9df77e) Initial commit

RELEASING.md

@@ -2,8 +2,6 @@
 
 Before releasing ensure that you have:
 - Decided on a release tag. The repo uses a 3 number semantic versioning system and therefore the tag should be of the form v.X.X.X e.g. v1.0.0. This value will be known in the rest of this document as `<RELEASE_TAG>`.
-- Run `.release/changelog.sh <PREVIOUS_RELEASE_TAG> <RELEASE_TAG>` to update CHANGELOG.md to contain all commits since the previous tag. Running without the previous release tag will get all commits.
-- Commit the updated changelog via PR with commit message "Preparing for release `<RELEASE_TAG>`"
 
 Releasing:
 - Go to: https://github.com/hyperledger/fabric-contract-api-go/releases
@@ -13,4 +11,4 @@ Releasing:
 - Add to the large textarea the release notes. These should consist of:
     - Include section called "Release Notes" containing the high-level view of changes made in the version that are of note.
     - (Optional) Include a section called "Migration Notes" detailing "gotchas" for the user of migrating to the new version.
-    - (Optional) Include a section called "Bug Fixes" detailing important bug fixes in the version. Should be listed as bullet points with a link to the JIRA for that bug.
+    - (Optional) Include a section called "Bug Fixes" detailing important bug fixes in the version.