Edit automation and documentation to drop develop (#4)

Given the relatively small size of the repo, it will be easier to use
to make PRs directly to the `main` branch, keeping the current tagging
schema intact.

PRs would still be required before merging to `main` following the
conventions described in `CONTRIBUTING.md`.

.github/release-drafter.yml

@@ -31,7 +31,7 @@ template: |
   ## Changes
   $CHANGES
 
-  **Full Changelog**: https://github.com/pinax-network/substreams-clock-api/compare/$PREVIOUS_TAG...v$RESOLVED_VERSION
+  **Full Changelog**: https://github.com/pinax-network/antelope-token-api/compare/$PREVIOUS_TAG...v$RESOLVED_VERSION
 
 autolabeler:
   - label: 'documentation'

.github/workflows/ghcr.yml

@@ -35,7 +35,7 @@ jobs:
           images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
           tags: |
             type=sha,prefix=
-            type=raw,enable=${{ github.ref == 'refs/heads/develop' }},value=develop
+            type=raw,enable=${{ !startsWith(github.ref, 'refs/tags/') }},value=develop
             type=semver,pattern={{raw}}
 
       - name: Build and push Docker image

CONTRIBUTING.md

@@ -98,9 +98,11 @@ Enhancement suggestions are tracked as [GitHub issues](https://github.com/pinax-
 
 You can follow the instructions from the `Quick Start` section of the [`README.md`](README.md/#quick-start) for setting up the environment.
 
-The repository contains two branches, `main` and `develop`. `main` represents the state of the latest stable release while `develop` is for active development of new features and bug fixes.
+The repository contains one `main` branch. Any changes to `main` must go through a pull request of a branch with a specific naming pattern (see below).
 
-PRs should be submitted from separate branches of the `develop` branch. Ideally, your PR should fall into one the following categories:
+Any push to `main` branch will be tagged with the commit hash and the latest commit will additionally be tagged with `develop` to enable pulling latest development image (this is done automatically). You can retrieve the latest stable version of the API by checking out the latest tagged version commit (following [*semver*](https://semver.org/)).
+
+PRs should be submitted from separate branches of the `main` branch. Ideally, your PR should fall into one the following categories:
 - **Feature**: `feature/xxx`
 - **Bug fix**: `fix/xxx`, try to make separate PRs for different bug fixes unless the change solves multiple bugs at once.
 - **Documentation**: `docs/xxx`, adding comments to files should be counted as documentation and changes made into a separate branch.