docs: add MAINTAINERS.md with versioning and branching strategy

[moul]

Please review this proposal for git tags.

[Gno2D2]

🛠 PR Checks Summary

All Automated Checks passed. ✅

Manual Checks (for Reviewers):

• IGNORE the bot requirements for this PR (force green CI check)

Read More

🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers.

✅ Automated Checks (for Contributors):

🟢 Maintainers must be able to edit this pull request (more info)

☑️ Contributor Actions:

1. Fix any issues flagged by automated checks.
2. Follow the Contributor Checklist to ensure your PR is ready for review.
   • Add new tests, or document why they are unnecessary.
   • Provide clear examples/screenshots, if necessary.
   • Update documentation, if required.
   • Ensure no breaking changes, or include BREAKING CHANGE notes.
   • Link related issues/PRs, where applicable.

☑️ Reviewer Actions:

1. Complete manual checks for the PR, including the guidelines and additional checks if applicable.

📚 Resources:

• Report a bug with the bot.
• View the bot’s configuration file.

Debug

Automated Checks

Maintainers must be able to edit this pull request (more info)

If

🟢 Condition met
└── 🟢 And
    ├── 🟢 The base branch matches this pattern: ^master$
    └── 🟢 The pull request was created from a fork (head branch repo: moul/gno)

Then

🟢 Requirement satisfied
└── 🟢 Maintainer can modify this pull request

Manual Checks

**IGNORE** the bot requirements for this PR (force green CI check)

If

🟢 Condition met
└── 🟢 On every pull request

Can be checked by

• Any user with comment edit permission

[davd-gzl]

If we cherry-pick and merge from master, we may have conflict and branch history will diverge. Should we have a preproduction branch for testing? master --> chain/test-gnoland1 --> chain/gnoland1

[moul]

If we never diverge, the master is limited by production, or production is misleading.

[sw360cab]

Can we agree that the official release in on git tag, whereas the release RC / preview is on branch chain/gnolandX.

This way production remains aligned to git tag, but other (production) staging environments can preview / experiment changes to production just aligning to the branch

the flow should be:

• master branch -> continuous deployment on staging
• chain/gnolandX -> RC on production staging environment (Cherry-pick or merge the relevant commits from master )
• v1.x.x -> official release to be deployed in production and reflecting mainnet (once RC is validated on branch chain/gnolandX)

[davd-gzl]

There's no mention of changelog / release note

[moul]

I don't care about this topic for now. I can't see it becoming a problem. I'll allow others to discuss it if they wish.

My focus is on the ongoing debate about Git tagging.

[davd-gzl]

How hotfix are communicated to validators? Do we have a precise workflow (discord / telegram ping, RSS feed, ...) + gnops documentation like "how to be an effective validator"?

[moul]

Validators deploy Git tags from chain branches, which can be either normal releases or hotfixes.

This document is intended for Git maintainers only, not for valopers or valoper coordinators.