Update maintainer guide (#1263)

* Update maintainer guide

* update makefile

Author: droserasprout

Makefile

@@ -67,6 +67,9 @@ docs_watch:     ## Build docs and watch for changes
 	python scripts/docs.py build --source docs --destination ${FRONTEND_PATH}/content/docs --watch
 
 docs_publish:   ## Tag and push `docs-next` ref
+	git tag -d docs && git tag docs && git push --force origin docs
+
+docs_publish_dev:   ## Tag and push `docs-next` ref
 	git tag -d docs-next && git tag docs-next && git push --force origin docs-next
 
 ##

docs/14.contributing.md

@@ -58,10 +58,21 @@ The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SH
 
 ### Git workflow
 
-- Default branches are `next` for the latest release and `current` for the previous one. `next` is the default branch for pull requests.
-- Branch names SHOULD follow the `prefix/short-description` format. Prefixes currently in use: `feat` for features, `fix` for bugfixes, `docs` for documentation, `exp` for experiments, `ref` for refactoring, `ci` for GitHub Actions, scripts and Docker stuff, `aux` for everything else.
+- Default branch for pull requests is `next`.
 - Commits in pull requests MUST be squashed when merging to `next`.
 - Issues and pull requests MUST have a descriptive title; they SHOULD be linked to each other, appropriately labeled, and assigned to maintainers while in progress.
+- Branch names SHOULD follow the `prefix/short-description` format.
+
+Consider using the following prefixes:
+
+- `feat` for features,
+- `fix` for bugfixes,
+- `docs` for documentation
+- `exp` for experiments
+- `ref` for refactoring
+- `ci` for GitHub Actions, scripts and Docker stuff
+- `bump` for version bumps
+- `aux` for everything else.
 
 ### Codestyle
 
@@ -81,13 +92,23 @@ We use several tools to enforce code style and quality: `ruff` for both formatti
 
 ### Documentation
 
-- We have a complex process of building and deploying docs. It starts with Markdown files in the `docs` directory. Then the `scripts/docs.py` script generates several dynamic pages, API references, processes custom Cookiecutter-style macros, and so on. The resulting Markdown is pushed to the private frontend repository via the `docs.yml` GitHub Action. The `docs.py` script code should answer most of your questions.
+We have a complex process of building and deploying docs. It starts with Markdown files in the `docs` directory. Then the `scripts/docs.py` script generates several dynamic pages, API references, processes custom Cookiecutter-style macros, and so on. The resulting Markdown is pushed to the private frontend repository `dipdup-io/interface` via the `docs.yml` GitHub Action. The `docs.py` script code should answer most of your questions.
+
 - All public APIs MUST be documented using docstrings. We use the reStructuredText (reST) syntax.
 - A page in the "Release notes" section MUST accompany all major and minor releases. Avoid using the `#include` macro in Release notes as they should not change after publication.
 
+#### Publishing docs
+
+To publish the docs you need to force-push `docs` or `docs-next` tags. Use the following table:
+
+| url           | `dipdup` tag | `interface` branch | description                       | command                 |
+| ------------- | ------------ | ------------------ | --------------------------------- | ----------------------- |
+| dipdup.io     | `docs`       | `master`           | Stable version docs               | `make docs_publish`     |
+| dev.dipdup.io | `docs-next`  | `dev`              | Latest docs and interface changes | `make docs_publish_dev` |
+
 ### Dependencies
 
-- All dependencies MUST be declared in the `pyproject.toml` file and pinned to non-breaking versions. We are more of an application than a library, so no asterisks, please.
+- All dependencies MUST be declared in the `pyproject.toml` file and pinned to non-breaking versions. Do not use extras until PEP 771 is implemented.
 
 ### Security
 
@@ -119,13 +140,15 @@ We use several tools to enforce code style and quality: `ruff` for both formatti
 Releasing a new version currently requires some manual actions:
 
 1. Ensure that all GitHub issues and PRs are closed and linked to the milestone.
-2. Checkout to an `aux/X.Y.Z` branch from `next`. Update DipDup version in `pyproject.toml`.
-3. Run `make before_release` to lock dependencies, dump `requirements.txt` files, generate demo projects, etc.
+2. Checkout to an `bump/X.Y.Z` branch from `next`. Update DipDup version in `pyproject.toml`.
+3. Run `make before_release` to lock dependencies, dump `requirements.txt` files, generate demo projects, docs, etc. Avoid adding other changes to this branch.
 4. Commit and push all changes with a message like `Bump version X.Y.Z`. Open a PR and link it to the milestone.
-5. Optionally, switch Docker images of hosted demos to the `aux-X.Y.Z` tag as a smoke test.
-6. Merge the PR, then `git tag X.Y.Z && git push origin X.Y.Z`. Wait for `release.yml` and `docs.yml` pipelines to finish.
+5. Optionally, temporary switch Docker images of hosted demos to the `aux-X.Y.Z` tag as a smoke test.
+6. Merge the PR, then `git tag X.Y.Z && git push origin X.Y.Z`. Wait for `release.yml` pipeline to finish.
 7. Announce the release on Twitter and Discord.
 
+This process should be automated in the future.
+
 ## MIT License
 
 <!-- markdownlint-disable first-line-h1 -->