Skip to content

New Release Policy

In order to finalize 3 years of microservices development and to switch from rolling release to more common release practice we introduce a new release policy.

Further NOC releases will be organized into Generations - milestones on NOC platform evolution. Generation is versioned by two or three numbers: X.Y[.Z], where X - is two last letters of year, Y - is sequental number of generation within year (starting from 1). Z - is an optional number of hotfix release (starting with 1) The distance between generations is about one month. Each generation holds first release, X.Y, followed by hotfix releases X.Y.Z.

NOC Release Policy

You can think of master branch as a tree's trunk, while each generation is a separate tree's branch (release-X.Y git branch). Particular releases are denoted by git tags.

Generation denote non-functional evolution of generation start release with following bugfixes in new hotfix releases. No new features, data migrations, incompatibilities or significant behaviour changes may be introduced during single generation.

Bugfixes are backported to last 3 generations. Hotfixes are released in case of serious problems discovered or as cumulative releases when next generation is started. So each generation will get around two hotfix releases until the end of support.

We strongly recommend to use git tags as deploy target. Several tags are available to cover common deploy scenarios:

  • latest - points to the top of master branch. Consider it as a bleeding edge of NOC development. latest tag is volatile and can be changed over the time. Deploying latest again and again you can get significant changes in system
  • X.Y, X.Y.Z - particular releases. This tags are stable. Deploying same release will lead you to same system
  • latest-X.Y - bleeding edge of generation X.Y. Usually includes fresh bugfixes still not bundled in future hotfix release. This tag is volatile, though not as strong as for latest.
  • stable-X.Y - last hotfix release in X.Y generation. This tag is volatile, though not introduces behavior changes or incompatiblities.
  • stable - last release in last generation. This tag is volatile and can change to new generation during consequent deployments.

So follow the simple rules:

  • Use stable-X.Y for production deployments. Deploy with new hotfix releases. (~1 per month).
  • Use X.Y if you bound to particular version. Deploy only for reconfigurations.
  • Use latest-X.Y in case you badly need bugfix still not packet to hotfix. Deploy on demand
  • Use stable for demonstration purposes
  • Use latest if you support DevTeam

See Release Policy documentation for more details.