RabbitLabs/droplet-next

Watch

Fork 0

Improve Git flow on this project #87

New issue

Open

opened 2026-09-17 18:33:30 +01:00 by Vylpes · 1 comment

Vylpes commented

2026-09-17 18:33:30 +01:00

Owner

Summary

Define and implement a consistent Git branching model for Droplet: integrate features on develop, ship production fixes from the production line, cut release/* branches for staging cycles, restrict staging deployments to release/hotfix lines, and require feature flags for in-progress user-facing work.

Acceptance Criteria

AS a contributor
GIVEN I am starting new feature work
WHEN I create a working branch
THEN it is based on develop and named with a feature/ prefix (e.g. feature/restructure)

AS a contributor
GIVEN I need an urgent production fix
WHEN I create a working branch
THEN it is based on the production line branch and named with a hotfix/ prefix

AS a release owner
GIVEN completed work on develop should be staged and tested
WHEN we begin a staging cycle
THEN a release/* branch is cut from develop for hardening and QA before production

AS CI/CD
GIVEN a change is pushed to the repository
WHEN the branch matches release/* or hotfix/*
THEN the staging deployment runs

AS CI/CD
GIVEN a change is pushed to the repository
WHEN the branch is develop or the production line branch
THEN the staging deployment does not run

AS a developer merging user-visible behaviour
GIVEN feature work is integrated before it is ready for general use
WHEN the change is on develop (or otherwise shared)
THEN access to that behaviour is controlled by a feature flag until explicitly enabled for staging/production

AS a new contributor
GIVEN I need to follow the team workflow
WHEN I read repository documentation and open a pull request
THEN the branching rules, release/hotfix process, deployment triggers, and feature-flag expectations are documented and reflected in PR checklists

Notes

Current long-lived branches observed: develop, main, release/0.1.0, plus active feature/* work.
Original notes: work from develop for features; production line for hotfixes; stage deploy only on release/* and hotfix/*; feature flag per feature; cut release when ready to stage.

Open decisions

See the latest comment from Smithy-bot — production branch naming, staging deploy mechanism, feature-flag standard, and deliverable scope need confirmation before criteria are final.

## Summary Define and implement a consistent Git branching model for Droplet: integrate features on `develop`, ship production fixes from the production line, cut `release/*` branches for staging cycles, restrict staging deployments to release/hotfix lines, and require feature flags for in-progress user-facing work. ## Acceptance Criteria AS a contributor GIVEN I am starting new feature work WHEN I create a working branch THEN it is based on `develop` and named with a `feature/` prefix (e.g. `feature/restructure`) AS a contributor GIVEN I need an urgent production fix WHEN I create a working branch THEN it is based on the production line branch and named with a `hotfix/` prefix AS a release owner GIVEN completed work on `develop` should be staged and tested WHEN we begin a staging cycle THEN a `release/*` branch is cut from `develop` for hardening and QA before production AS CI/CD GIVEN a change is pushed to the repository WHEN the branch matches `release/*` or `hotfix/*` THEN the staging deployment runs AS CI/CD GIVEN a change is pushed to the repository WHEN the branch is `develop` or the production line branch THEN the staging deployment does not run AS a developer merging user-visible behaviour GIVEN feature work is integrated before it is ready for general use WHEN the change is on `develop` (or otherwise shared) THEN access to that behaviour is controlled by a feature flag until explicitly enabled for staging/production AS a new contributor GIVEN I need to follow the team workflow WHEN I read repository documentation and open a pull request THEN the branching rules, release/hotfix process, deployment triggers, and feature-flag expectations are documented and reflected in PR checklists ## Notes - Current long-lived branches observed: `develop`, `main`, `release/0.1.0`, plus active `feature/*` work. - Original notes: work from `develop` for features; production line for hotfixes; stage deploy only on `release/*` and `hotfix/*`; feature flag per feature; cut release when ready to stage. ## Open decisions See the latest comment from Smithy-bot — production branch naming, staging deploy mechanism, feature-flag standard, and deliverable scope need confirmation before criteria are final.

Vylpes added this to the 0.2.0 milestone

2026-09-17 18:33:30 +01:00

Vylpes added the

labels

2026-09-17 18:33:30 +01:00

Smithy-bot was assigned by Vylpes

2026-09-17 18:33:30 +01:00

Smithy-bot removed their assignment

2026-09-27 12:01:46 +01:00

Vylpes was assigned by Smithy-bot

2026-09-27 12:01:46 +01:00

Smithy-bot added the

question

label

2026-09-27 12:01:46 +01:00

Smithy-bot commented

2026-09-27 12:01:46 +01:00

Member

Planning questions (needs/criteria)

I drafted acceptance criteria on the issue body from your bullets. A few decisions are ambiguous from the repo state alone — please reply here so I can finalize criteria and move to needs/estimate.

Production branch name — The issue text says master, but this repo’s protected production branch is main (no master branch). Should the flow use main, should we rename/create master, or is master just shorthand for the production line?
Staging deployment — What exactly is “deploy stage”? (Forgejo Actions workflow, external CD, manual deploy, etc.) I did not find workflow definitions under .forgejo/workflows on feature/restructure. Is there an existing pipeline/environment URL this issue should wire up, or is adding CI part of the deliverable?
Deliverable scope — Should “done” include documentation + PR templates only, or also branch protection rules and CI on.push branch filters?
Feature flags — What mechanism should we standardize on (e.g. Microsoft.FeatureManagement, appsettings/env flags, other)? Must every user-facing story use a flag, or only work that ships incomplete behind develop?
Hotfix merge-back — After a hotfix/* ships to production, should it be merged back into develop and any open release/* branches?
Release branch convention — Confirm naming (release/{semver} only) and who cuts the branch; after staging sign-off, does the release merge to the production line only, or production + back-merge to develop?

Once these are answered I’ll tighten the acceptance criteria, remove the question label, re-assign Smithy-bot, and advance to needs/estimate.

### Planning questions (needs/criteria) I drafted acceptance criteria on the issue body from your bullets. A few decisions are ambiguous from the repo state alone — please reply here so I can finalize criteria and move to **needs/estimate**. 1. **Production branch name** — The issue text says `master`, but this repo’s protected production branch is `main` (no `master` branch). Should the flow use `main`, should we rename/create `master`, or is `master` just shorthand for the production line? 2. **Staging deployment** — What exactly is “deploy stage”? (Forgejo Actions workflow, external CD, manual deploy, etc.) I did not find workflow definitions under `.forgejo/workflows` on `feature/restructure`. Is there an existing pipeline/environment URL this issue should wire up, or is adding CI part of the deliverable? 3. **Deliverable scope** — Should “done” include **documentation + PR templates only**, or also **branch protection rules** and **CI `on.push` branch filters**? 4. **Feature flags** — What mechanism should we standardize on (e.g. `Microsoft.FeatureManagement`, appsettings/env flags, other)? Must **every** user-facing story use a flag, or only work that ships incomplete behind `develop`? 5. **Hotfix merge-back** — After a `hotfix/*` ships to production, should it be merged back into `develop` and any open `release/*` branches? 6. **Release branch convention** — Confirm naming (`release/{semver}` only) and who cuts the branch; after staging sign-off, does the release merge to the production line only, or production + back-merge to `develop`? Once these are answered I’ll tighten the acceptance criteria, remove the **question** label, re-assign **Smithy-bot**, and advance to **needs/estimate**.

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

RabbitLabs/droplet-next#87

No description provided.

Rows
Columns