Skip to content

Maintenance Procedure

Jump to bottom
Chris Philips edited this page Jul 4, 2022 · 6 revisions

Milestones

Stable Version Number

This type of milestone has a title that is a semantic version number with no prerelease or metadata tags (e.g., 7.0.0). Once a Release has been made for the milestone, copy the Release notes into the description of the milestone; if there was no milestone due date, put the date that the Release was deployed as the due date. Finally, close the Milestone!

Other

In the future, there may be other types of milestones 🤷‍♂️

Labels

All labels come with a description of how to use them. Related labels will start with a common prefix (e.g., diff:)

Issues

  1. All code changes should be described in as much detail as needed by issues
  2. The issue should be assigned to either yourself or someone else
  3. The issue should be labeled for feature or bug or enhancement
  4. The issue should be linked to a stable Version Number milestone

Pull Requests

  1. All code changes which affect the package (excluding metadata such as README or ICON) should be merged into the default branch through pull requests
  2. The pull request should be assigned to either yourself or someone else
  3. The pull request should be labeled for diff
  4. The pull request should be linked to a Stable Version Number milestone
  5. The pull request should be linked to any related issues by using Closing keywords in the description

Pull Requests are deployed to the beta environment which is hosted on MyGet.

Whenever a pull request is opened or receives new pushes, it will trigger the Publish to Beta workflow, which is what triggers the deployment.

To add this source to your project, run the following command:

dotnet nuget add source https://www.myget.org/F/entitydb-io-beta/api/v3/index.json -n 'EntityDb Beta'

Default Branch

Whenever code has been merged to the default branch, the Build workflow will be triggered. This workflow runs the tests that update coverage and quality scores, and the status of this workflow (as well as the status of coverage and quality) is displayed from the README.

Merging

My personal feeling is that commits should be Squashed into the default branch. The commit history is easier to follow because every commit links back to a Pull Request. If you need to see the original commits, they are available on the Pull Request, and if you want to do a binary search for a bug, you can do one pass to locate the pull request, then do another search on the branch for that pull request. (If the pull request's branch was deleted, GitHub provides a feature to restore the branch. The button is on the closed pull request's page, and it is labeled Restore branch)

Releases

Once code has been squash-merged to the default branch, it's ready to be deployed to the stable environment, which is hosted on NuGet

In order to start the deployment procedure, you just need to Draft a new release.

  1. Click on the Choose a tag drop-down. In the input with the placeholder Find or create a new tag, enter a Stable Version Number (there should be a corresponding Milestone)

  2. Make sure the Target drop-down is the default branch

  3. You do not need to specify a Release Title, but feel free to. I've seen some repositories use what appear to be randomly generated code names. That might be fun!

  4. Directly above the top right corner of the Description input is a button Generate release notes. Click on that. It will list all of the pull requests for the release in the description. You are free to add any additional description you want.

  5. If you're not ready to release, click Save draft. It will be listed in the releases with a badge of Draft. Click on the pencil icon to get back to the editor page.

  6. Once you're ready to release the new packages, click on Publish release. This will start the Publish to Stable workflow.

  7. Stable deployments need to be approved by @the-avid-engineer

Clone this wiki locally