When we do a release, we will create a release candidate branch and tag the commit for each version of the release in that branch. When a rc branches and tags are named by the current year and the release number of that year. Release tags include the revision of the release.
Development happens on the dev branch
Tickets are implemented in branches and then merge in after an approved pull request
- Branch Scheme:
Ticket Name-word or two description - Such As: Ticket fix as a table feature might be:
Firefly-123456-table-sort - Such As: Ticket fix an image bug:
Firefly-456-image-zoom
- Branch Scheme:
rc- year . release # of that year - Such as:
rc-2019.2
Example: The first release of 2019 branch name will the rc-2019.1, the next one will be rc-2019.2
Firefly will use tags to label a release, a prerelease and a development cycles.
-
Tag Scheme:
release- year . release # of that year . revision of release -
Such as:
release-2019.2.3Example: The release versions for the second 2022 release branch will be tagged.
release-2022.2.0,release-2022.2.1,release-2022.2.2, etc. These tags will all be in therc-2022.2branch.
- Tag Scheme:
pre- prerelease number - year . release # of that year - Such as:
pre-2-2019.2
Example: The prerelease versions third 2023 dev cycle will be tagged. pre-1-2023.3, pre-2-2023.3, pre-3-2023.3, etc. These tags will all be in the dev branch.
At the beginning of a development cycle in the dev branch, the first commit will be tagged with the cycle number.
- Tag Scheme:
cycle- year . release # of that year - Such as:
cycle-2022.4
Example: After the2022.2.0 release. The first commit in the dev branch will label the next cycle. It will be tagged cycle-2022.3