# 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