Tsugi is intended as a continuously upgraded cloud deployment. Most of the Dr. Chuck servers have a cron job that does a git pull and runs upgrade.php *every 30 minutes*.  You can see this infrastructure at:

https://github.com/tsugiproject/tsugi-build/tree/master/common

As a result, there are no traditional “feature releases” of Tsugi – the common use case is to be pretty close to the tip of the main branch. Features just come out.

But sometimes, folks want to “hold back” from upgrading for a while. Perhaps they have an old version of PHP and can’t run the latest. It is always risky to hold back too long. Releases are tags – not branches.

There is no intent to ever back-port anything in Tsugi to a prior release unless the adopting community wants to make a branch and maintain it. Dr. Chuck follows the “first rule of Italian driving” when it comes to cloud based software development.

But to help those running Tsugi that want to hold back, a series of versions / tags are maintained as “safe plateaus”. These tags are often snapped right before a significant upgrade or data model change and announced on the dev list.

These versions originally were the classic geek-style ‘0.x.0’ releases that pretended that we never reach 1.0 .

As of December 2020, we are switching to a year.month.patch approach to Tsugi versioning, adapting from the Linux model.

The releases will continue to be snapped at stable places, often right before significant new development is going to be merged.

I just snapped the 20.12.0 release – because it is December and I wanted a 2020 release.