Skip to content

Use non-squash back-merge for releases to prevent main↔develop divergence #226

@kirich1409

Description

@kirich1409

During the v1.0.0 release, developmain and the back-merge (#222) were squash-merged. A squash collapses the merge, so the release merge commit and the CI-generated Package.swift bot commit on main do not become ancestors of develop.

Consequence: main accumulates commits (release merges + Package.swift bot updates) that never flow back into develop by history, so each subsequent release shows main "ahead" and risks the same divergence that required a manual reconcile this release (when main had unmerged commits #217/#218 + a competing release commit).

Proposal: adopt a true gitflow back-merge — after each release, merge main into develop with a real merge commit (--no-ff, not squash), and consider a merge commit (not squash) for developmain. Document the release branching/merge procedure in CONTRIBUTING.

Metadata

Metadata

Assignees

No one assigned

    Labels

    choreMaintenance and housekeeping tasks

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions