Git workflow (+Release process)

[dongwon8247]

Git Workflow

• main: This branch stores the source code of the latest released version of Adena.
• release/*: Release branch for a specific version, including QA and final review.
• hotfix/*: Branch for critical bugs.
• develop: Branch for ongoing development.
• feature branches: Branches for specific features or enhancements.

Release Process

1. Develop features in the developbranch (following the work process in #300).
2. When finished, create a release/* branch for QA.
3. When QA is complete, submit the final review to @dongwon8247.
4. After merging the release/* branch into main upon approval, submit a review to the Chrome Web Store.
5. (If approved) Create official releases and tags with updated features/bug fixes.
   • Releases: https://github.com/onbloc/adena-wallet/releases
   • Tags: https://github.com/onbloc/adena-wallet/tags
   • Patch notes: https://medium.com/@adena.app
   • Community update in Twitter and Discord
6. (If rejected) Create a feature branch, fix the issue, and resubmit for review.

[dongwon8247]

@moul @michelleellen @zivkovicmilos @clockworkgr Please check the above release process of Adena. For the final review by the Gno team before releasing a new version of Adena to the public, how about we request a review when the QA is complete in the release/* branch (before merging it into main)?

EDIT: Add a code release label and deadline when requesting.

[michelleellen]

I would suggest adding a different label like code review or code release. I would also add deadline, linked to each release.

[moul]

In my opinion, your process is too complex. It resembles an advanced git-flow. I recommend considering the github-flow instead.

The github-flow primarily involves a main branch where you attempt to merge the current state. You then create branches for PRs.

To simplify things, try to use git tags exclusively on the main branch whenever possible. This can serve two purposes: freezing the git at a specific hash for review (share us the link), or marking an official release (after review). For example, you can use tags like v0.0.1-prerelease for review and then v0.0.1 for the final release.

In certain cases, you may have dedicated branches for special releases. For instance, we use this approach for each testnet. It allows us to add additional commits, such as hotfixes or configuration changes. However, the main focus should always be on the main branch. Git tags are used either to freeze the code or to make a release.

---

In other words, I would:

• Remove the develop branch.
• Avoid using hotfix/ branches.
• Utilize more tags.
• Occasionally use release/ branch for new commits in a release, otherwise, just use a tag.

[clockworkgr]

Hello everyone,

I agree with Manfred that a simplified flow would be better.

Specifically, when it comes to a chrome extension, the concept of an "earlier" version does not exist. Hence hotfixes or backports to earlier versions are of absolutely no use since users are ALWAYS at latest version.

Thus @moul 's suggestion of using tags (imho using semver) is the most appropriate.

The only addition that MAY be useful is release branches once you hiit RC level near a release assuming the scenario that there are people continuing implementing/merging features that will NOT be included in the release. Thus any bug-fixes or adjustments that result from testing should be done on that release branch until you get to the final submitted release and then merged back to main.

However the size of the project and team does not warrant that imo.