Skip to content

Branch structure and dependency constraints #141

@macintoshplus

Description

@macintoshplus

In my opinion, the master branch (which should be renamed to main for consistency) should allow you to install Bolt with development versions of Bolt dependencies.

composer.json example:

{
  "require": {
    "bolt/core": "dev-main",
  },
}

Then, as with the bolt/core repository, there should be one branch per version (such as 5.0, 5.1, 5.2) that allows you to install the development versions of these branches (example command composer create-project bolt/project bolt_dev_5.2 dev-5.2 to install Bolt 5.2 in development version).

composer.json example:

{
  "require": {
    "bolt/core": "dev-5.2",
  },
}

When a version is released, the version branch is created, the constraints in the composer.json file are changed, and the tag is created; finally, the constraints are changed to the development version.

Example: On project repository branch master, the bolt/core dependency constraint is dev-main.
When bolt/core version 6.0.0 is released, the branch 6.0 is created on the repository project, and the bolt/core dependency constraints are changed to ~6.0. The change is committed, and a tag 6.0.0 is created. Finally, the bolt/core dependency constraint is changed to dev-6.0 and committed.

I'm not sure if this workflow is realistic for Bolt, but can allows for installation development version.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions