# Trinsic Core Versioning and Release Strategy
* **Proper** Semantic Versioning semver.org
* SemVer for Nuget and NPM
* PEP440 for Python (it honors semver)
* We use `[MAJOR].[MINOR].[PATCH]` for production releases
* Beta releases versioning can vary in format among languages
* For web service automatically generated SDKs, versioning should be less important
* When is a release done?
* For services, a rolling release model where possible (deploy on Monday at 12PM EST/10AM MST/9AM PST, canary load balancer over 6-8 hrs to migrate traffic)
* Ensure easy rollback to allow for low-stress deployments
* For SDK bindings, automatically generated and deployed whenever the API surface changes
* Review existing language bindings?
* At least once a month, ideally more often.
* Automated tooling to help identify when bindings need updating.
* How is a release done/triggered?
* Triggered from Github, create a tag for the release
* Tag format is `v[MAJOR].[MINOR].[PATCH]`
* Automated Github actions handle build, pack, & deploy to appropriate package repositories
* Do we notify customers? If so, how?
* How are pre-releases handled?
* Python version will be `[MAJOR].[MINOR].[PATCH]b[REV NUMBER]`
* If on a rolling release model, deploy nightly based upon the latest in `main`
* If on a manual release model, whenever needed by a member of the development team
* Again, easy rollbacks make for easier development deploys
* Release checklist
* Everything builds? All tests pass?
* Tell on-call people, get their approval (so they aren't caught off guard by any pagerduty alerts)
* Any new endpoints that need to be added to client-side SDKs?
* Check new/updated instances via canary
* Watch for traffic cutover
* Automated smoke testing
Automation API
- Work on backend code in server
- Process of deployment
- Create asp.net core service
- Management and hook in monitoring for each stack.
- Ensure all version tags are updated for each language SDK.
- Create all packages and service wrappers automatically
- Github actions to trigger all required processes