MVP development space for Queensland Government Design System (QGDS) Bootstrap 5 implementation, Dist folder located in https://github.com/qld-gov-au/qgds-qol-mvp-release
The deployment pipeline for the release repo is based on any branches haves a successful release, this includes tags.
The cdn is only updated by tagged releases. It cannot have anything that is in active development unless a person with the correct permissions does a version cut.
What branch will used for version incrementing.
The convention would be to only do version cuts on main and the increment pull back into develop so we don't have desync on version details.
The system is designed to allow freedom on which branch is used to do a point, minor or major npm version bump. This also triggers a git tag to be created that matches the package.json version (as well as trigger package distribution deployments).
There is a scheduled job that does a point increment weekly if there is any delta on the 'default' branch, this triggers Monday's 11ish.
As Discussed with @stvp-qld on 2024/07/04, This PR is open to allow @stvp-qld to review and Propagate branch
develop
intomain
.After this, the 'default' branch will be set to
main
. Generally, versioning will be done on main and then backported to develop.Notes:
How would work in progress get to a production/version.
It would go through two Pull Requests
develop
tomain
for file peer review.For externals not part of the qld-gov-au organisation, they can
fork
the repo, make their changes in their own feature branch and raise a Pull Request back for contribution. https://www.atlassian.com/git/tutorials/comparing-workflowsHow will this affect the Deployment Pipeline
There is two parts to this:
tagged
releases. It cannot have anything that is in active development unless a person with the correct permissions does a version cut.What branch will used for version incrementing.
The convention would be to only do version cuts on
main
and the increment pull back into develop so we don't have desync on version details.The system is designed to allow freedom on which branch is used to do a point, minor or major npm version bump. This also triggers a git tag to be created that matches the package.json version (as well as trigger package distribution deployments).
There is a scheduled job that does a point increment weekly if there is any delta on the 'default' branch, this triggers Monday's 11ish.