Improve git flow on this project #39

New issue

Open

opened 2026-09-17 18:33:04 +01:00 by Vylpes · 5 comments

Vylpes commented 2026-09-17 18:33:04 +01:00

Owner

Copy link

Story Points: 3

---

Summary

Align Calculator’s Git flow and Forgejo Actions CI so feature work integrates on develop, production fixes use main, staging builds run only from release/* and hotfix/*, and hotfixes are merged back through the release lines.

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/11-forgejo-actions)

AS a contributor
GIVEN I need an urgent production fix
WHEN I create a working branch
THEN it is based on main 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/{semver} 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 is release/* or hotfix/* only
THEN the staging workflow (.forgejo/workflows/stage.yml) runs and produces the stage build artifact (e.g. vyxcalc)

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

AS CI/CD
GIVEN workflow definitions currently exist on cursor/11-forgejo-actions
WHEN this issue is implemented
THEN the Forgejo Actions workflow files are updated on develop with staging triggers restricted as above

AS a developer integrating incomplete user-facing behaviour
GIVEN a story may ship to develop before it is ready for all users
WHEN a feature flag is appropriate for that story
THEN we use Cargo feature flags (team default); flags are adopted when they make sense, not required on every user-facing change

AS a release owner handling hotfixes
GIVEN a hotfix/* branch has been validated and shipped
WHEN merges are completed
THEN changes flow hotfix/* → main → develop → open release/* branches as applicable

AS a release owner merging to production
GIVEN a release/* or hotfix/* line is ready
WHEN changes land on main
THEN merges use the repository’s normal merge strategy (as on release/0.1.0 today), not a squash-only requirement

Scope

• CI workflow changes only (staging trigger branches, merge workflow YAML to develop)
• Production branch: main

Out of scope

• Branch protection configuration changes
• Standalone documentation / PR-template-only work
• Renaming existing cursor/* branches to feature/*

Notes

• Long-lived branches observed: develop, main, release/0.1.0.
• Prior stage.yml on cursor/11-forgejo-actions also triggered on main and develop; this issue removes those triggers.
• Decisions recorded from @Vylpes (2026-09-30).

Story Points: 3 --- ## Summary Align Calculator’s Git flow and **Forgejo Actions CI** so feature work integrates on `develop`, production fixes use `main`, staging builds run only from `release/*` and `hotfix/*`, and hotfixes are merged back through the release lines. ## 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/11-forgejo-actions`) AS a contributor GIVEN I need an urgent production fix WHEN I create a working branch THEN it is based on **`main`** 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/{semver}`** 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 is **`release/*` or `hotfix/*` only** THEN the staging workflow (`.forgejo/workflows/stage.yml`) runs and produces the stage build artifact (e.g. `vyxcalc`) AS CI/CD GIVEN a change is pushed to the repository WHEN the branch is `develop` or `main` THEN the staging workflow **does not** run AS CI/CD GIVEN workflow definitions currently exist on `cursor/11-forgejo-actions` WHEN this issue is implemented THEN the Forgejo Actions workflow files are updated on **`develop`** with staging triggers restricted as above AS a developer integrating incomplete user-facing behaviour GIVEN a story may ship to `develop` before it is ready for all users WHEN a feature flag is appropriate for that story THEN we use **Cargo feature flags** (team default); flags are adopted **when they make sense**, not required on every user-facing change AS a release owner handling hotfixes GIVEN a `hotfix/*` branch has been validated and shipped WHEN merges are completed THEN changes flow **`hotfix/*` → `main` → `develop` → open `release/*` branches** as applicable AS a release owner merging to production GIVEN a `release/*` or `hotfix/*` line is ready WHEN changes land on `main` THEN merges use the repository’s **normal merge** strategy (as on `release/0.1.0` today), not a squash-only requirement ## Scope - **CI workflow changes only** (staging trigger branches, merge workflow YAML to `develop`) - Production branch: **`main`** ## Out of scope - Branch protection configuration changes - Standalone documentation / PR-template-only work - Renaming existing `cursor/*` branches to `feature/*` ## Notes - Long-lived branches observed: `develop`, `main`, `release/0.1.0`. - Prior `stage.yml` on `cursor/11-forgejo-actions` also triggered on `main` and `develop`; this issue removes those triggers. - Decisions recorded from @Vylpes (2026-09-30).

Vylpes added this to the 0.2.0 milestone 2026-09-17 18:33:04 +01:00

Vylpes added the

needs

criteria

type

change

labels 2026-09-17 18:33:04 +01:00

Smithy-bot was assigned by Vylpes 2026-09-17 18:33:04 +01:00

Smithy-bot commented 2026-09-30 12:07:10 +01:00

Member

Copy link

Planning questions (needs/criteria)

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

1. Production branch name — The issue text says master, but the protected production branch here is main (no master). Should the flow use main, or do you want master created/renamed?

2. Staging workflow — On cursor/11-forgejo-actions, stage.yml builds/tests and uploads a vyxcalc artifact. Is that the intended “deploy stage”, and should this issue include merging those workflows to develop plus restricting on.push.branches to release/* and hotfix/* only?

3. Deliverable scope — Should “done” include documentation + PR templates only, or also CI workflow changes, branch protection updates, and cleaning up branch naming (cursor/* vs feature/*)?

4. Feature flags — For this Rust CLI/GUI app, what should we standardize on (Cargo feature flags, compile-time cfg, runtime env/config file, other)? Must every user-facing story ship behind a flag, or only incomplete work integrated to develop?

5. Hotfix merge-back — After a hotfix/* ships to production, should it merge back into develop and any open release/* branches?

6. Release branch convention — Confirm naming (release/{semver} only) and whether production merges are squash-only via PR as today on release/0.1.0.

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 and what is in the repo today. A few decisions are ambiguous — please reply here so I can finalize criteria and move to **needs/estimate**. 1. **Production branch name** — The issue text says `master`, but the protected production branch here is `main` (no `master`). Should the flow use `main`, or do you want `master` created/renamed? 2. **Staging workflow** — On `cursor/11-forgejo-actions`, `stage.yml` builds/tests and uploads a `vyxcalc` artifact. Is that the intended “deploy stage”, and should this issue include merging those workflows to `develop` plus restricting `on.push.branches` to `release/*` and `hotfix/*` only? 3. **Deliverable scope** — Should “done” include **documentation + PR templates only**, or also **CI workflow changes**, **branch protection** updates, and cleaning up branch naming (`cursor/*` vs `feature/*`)? 4. **Feature flags** — For this Rust CLI/GUI app, what should we standardize on (Cargo feature flags, compile-time cfg, runtime env/config file, other)? Must **every** user-facing story ship behind a flag, or only incomplete work integrated to `develop`? 5. **Hotfix merge-back** — After a `hotfix/*` ships to production, should it merge back into `develop` and any open `release/*` branches? 6. **Release branch convention** — Confirm naming (`release/{semver}` only) and whether production merges are squash-only via PR as today on `release/0.1.0`. Once these are answered I’ll tighten the acceptance criteria, remove the **question** label, re-assign **Smithy-bot**, and advance to **needs/estimate**.

Smithy-bot removed their assignment 2026-09-30 12:07:10 +01:00

Vylpes was assigned by Smithy-bot 2026-09-30 12:07:10 +01:00

Smithy-bot added the

question

label 2026-09-30 12:07:16 +01:00

Vylpes commented 2026-09-30 13:36:15 +01:00

Author

Owner

Copy link

@Smithy-bot wrote in #39 (comment):

Planning questions (needs/criteria)

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

1. **Production branch name** — The issue text says `master`, but the protected production branch here is `main` (no `master`). Should the flow use `main`, or do you want `master` created/renamed?

2. **Staging workflow** — On `cursor/11-forgejo-actions`, `stage.yml` builds/tests and uploads a `vyxcalc` artifact. Is that the intended “deploy stage”, and should this issue include merging those workflows to `develop` plus restricting `on.push.branches` to `release/*` and `hotfix/*` only?

3. **Deliverable scope** — Should “done” include **documentation + PR templates only**, or also **CI workflow changes**, **branch protection** updates, and cleaning up branch naming (`cursor/*` vs `feature/*`)?

4. **Feature flags** — For this Rust CLI/GUI app, what should we standardize on (Cargo feature flags, compile-time cfg, runtime env/config file, other)? Must **every** user-facing story ship behind a flag, or only incomplete work integrated to `develop`?

5. **Hotfix merge-back** — After a `hotfix/*` ships to production, should it merge back into `develop` and any open `release/*` branches?

6. **Release branch convention** — Confirm naming (`release/{semver}` only) and whether production merges are squash-only via PR as today on `release/0.1.0`.

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

1. Use main
2. Only hotfix/* and release/*
3. just CI workflow changes
4. Choose recommended, we can decide feature flags as and when they make sense
5. Yes, from hotfix -> main -> develop -> release/*
6. Correct, normal merges

@Smithy-bot wrote in https://git.vylpes.xyz/RabbitLabs/calculator/issues/39#issuecomment-22757: > ### [](#planning-questions-needs-criteria)Planning questions (needs/criteria) > > I drafted acceptance criteria on the issue body from your bullets and what is in the repo today. A few decisions are ambiguous — please reply here so I can finalize criteria and move to **needs/estimate**. > > 1. **Production branch name** — The issue text says `master`, but the protected production branch here is `main` (no `master`). Should the flow use `main`, or do you want `master` created/renamed? > > 2. **Staging workflow** — On `cursor/11-forgejo-actions`, `stage.yml` builds/tests and uploads a `vyxcalc` artifact. Is that the intended “deploy stage”, and should this issue include merging those workflows to `develop` plus restricting `on.push.branches` to `release/*` and `hotfix/*` only? > > 3. **Deliverable scope** — Should “done” include **documentation + PR templates only**, or also **CI workflow changes**, **branch protection** updates, and cleaning up branch naming (`cursor/*` vs `feature/*`)? > > 4. **Feature flags** — For this Rust CLI/GUI app, what should we standardize on (Cargo feature flags, compile-time cfg, runtime env/config file, other)? Must **every** user-facing story ship behind a flag, or only incomplete work integrated to `develop`? > > 5. **Hotfix merge-back** — After a `hotfix/*` ships to production, should it merge back into `develop` and any open `release/*` branches? > > 6. **Release branch convention** — Confirm naming (`release/{semver}` only) and whether production merges are squash-only via PR as today on `release/0.1.0`. > > > Once these are answered I’ll tighten the acceptance criteria, remove the **question** label, re-assign **Smithy-bot**, and advance to **needs/estimate**. 1. Use `main` 2. Only `hotfix/*` and `release/*` 3. just CI workflow changes 4. Choose recommended, we can decide feature flags as and when they make sense 5. Yes, from hotfix -> main -> develop -> release/* 6. Correct, normal merges

Vylpes removed their assignment 2026-09-30 13:36:22 +01:00

Smithy-bot was assigned by Vylpes 2026-09-30 13:36:22 +01:00

Vylpes removed the

question

label 2026-09-30 13:36:25 +01:00

Smithy-bot commented 2026-10-03 16:11:59 +01:00

Member

Copy link

needs/criteria → needs/estimate

Thanks @Vylpes — incorporated your answers into the issue body (production on main, stage CI only on release/* and hotfix/*, scope limited to workflow YAML on develop, Cargo feature flags when useful, hotfix merge-back path, normal merges on release lines).

Next planning step: story point estimate.

**needs/criteria → needs/estimate** Thanks @Vylpes — incorporated your answers into the issue body (production on `main`, stage CI only on `release/*` and `hotfix/*`, scope limited to workflow YAML on `develop`, Cargo feature flags when useful, hotfix merge-back path, normal merges on release lines). Next planning step: story point estimate.

Smithy-bot added

needs

estimate

and removed

needs

criteria

labels 2026-10-03 16:11:59 +01:00

Smithy-bot commented 2026-10-04 12:08:44 +01:00

Member

Copy link

Story point estimate (needs/estimate)

Estimate: 3

Scope is limited to Forgejo Actions workflow YAML on develop (merge from cursor/11-forgejo-actions and restrict stage.yml push triggers to release/* and hotfix/* only). Acceptance criteria are clear; no app code changes.

Slice	Points	Notes
Port/update .forgejo/workflows/* on develop from the feature branch	1	Align with existing stage.yml / artifact pattern
Restrict staging workflow branch filters (release/*, hotfix/*; exclude develop/main)	1	Verify YAML matches agreed git flow
Validate workflows on a test push to release/* or hotfix/* (and confirm no run on develop)	1	Manual CI verification
Total	3

Comparable effort to a small infra change; lower than multi-module CLI stories (5 pts) because deliverable is CI config only.

---

Advancing needs/estimate → needs/tests. Story Points set to 3 on the issue body.

## Story point estimate (needs/estimate) **Estimate: 3** Scope is limited to Forgejo Actions workflow YAML on `develop` (merge from `cursor/11-forgejo-actions` and restrict `stage.yml` push triggers to `release/*` and `hotfix/*` only). Acceptance criteria are clear; no app code changes. | Slice | Points | Notes | |-------|--------|-------| | Port/update `.forgejo/workflows/*` on `develop` from the feature branch | 1 | Align with existing `stage.yml` / artifact pattern | | Restrict staging workflow branch filters (`release/*`, `hotfix/*`; exclude `develop`/`main`) | 1 | Verify YAML matches agreed git flow | | Validate workflows on a test push to `release/*` or `hotfix/*` (and confirm no run on `develop`) | 1 | Manual CI verification | | **Total** | **3** | | Comparable effort to a small infra change; lower than multi-module CLI stories (5 pts) because deliverable is CI config only. --- Advancing **needs/estimate → needs/tests**. Story Points set to **3** on the issue body.

Smithy-bot removed the

needs

estimate

label 2026-10-04 12:08:52 +01:00

Smithy-bot removed their assignment 2026-10-04 12:09:24 +01:00

Vylpes was assigned by Smithy-bot 2026-10-04 12:09:24 +01:00

Smithy-bot commented 2026-10-04 12:09:24 +01:00

Member

Copy link

needs/estimate complete (label transition blocked)

Story point estimate (3) is posted above and Story Points: 3 is on the issue body.

I removed needs/estimate but could not apply the next planning label: the RabbitLabs org has needs/criteria (215), needs/estimate (216), and needs/approval (272), but no needs/test / needs/tests label ID is available via the API (adding candidate IDs does not attach a tests label).

Please either:

1. Confirm the correct needs/tests (or needs/test) label exists on RabbitLabs and re-apply it, or
2. Create that label in the org label set,

then re-assign Smithy-bot so the next run can write QA scripts and advance to needs/approval.

Assigning Vylpes until resolved. question label added.

**needs/estimate complete (label transition blocked)** Story point estimate (**3**) is posted above and `Story Points: 3` is on the issue body. I removed `needs/estimate` but could not apply the next planning label: the RabbitLabs org has `needs/criteria` (215), `needs/estimate` (216), and `needs/approval` (272), but no `needs/test` / `needs/tests` label ID is available via the API (adding candidate IDs does not attach a tests label). Please either: 1. Confirm the correct **needs/tests** (or **needs/test**) label exists on RabbitLabs and re-apply it, **or** 2. Create that label in the org label set, then re-assign **Smithy-bot** so the next run can write QA scripts and advance to `needs/approval`. Assigning **Vylpes** until resolved. `question` label added.

Smithy-bot added the

question

label 2026-10-04 12:09:24 +01:00

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

release/0.1.0

develop

No results found.

Labels

Clear labels

  

blocked

  

duplicate

  

high priority

  

needs

approval

  

needs

criteria

  

needs

estimate

  

needs

tests

  

question

  

step

doing

  

step

review

  

step

testing

  

step

todo

  

step

uat

  

type

admin

  

type

alert

  

type

bug

  

type

change

  

type

defect

  

type

dependencies

  

type

development

  

type

documentation

  

type

epic

  

type

idea

  

type

incident

  

type

investigation

  

type

spike

  

type

story

  

type

tests

  

won't fix

No labels

blocked

duplicate

high priority

needs

approval

needs

criteria

needs

estimate

needs

tests

question

step

doing

step

review

step

testing

step

todo

step

uat

type

admin

type

alert

type

bug

type

change

type

defect

type

dependencies

type

development

type

documentation

type

epic

type

idea

type

incident

type

investigation

type

spike

type

story

type

tests

won't fix

Milestone

Clear milestone

No items

No milestone

0.2.0

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

Vylpes

2 participants

Notifications

Subscribe

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/calculator#39

No description provided.