Trellis 1.0.0 has finally been released. It’s been a long and exciting path since the very first commit on Apr 16, 2014 (back when it was first called bedrock-ansible!). That was so long ago the project started on Ubuntu 14.04 and PHP 5.5.
What does 1.0.0 mean?
A common belief seems to be that 1.0.0 means software is finally production ready. Maybe that’s true of some software, but it’s definitely not for Trellis. It’s impossible to know this for sure, but I’d have to guess Trellis has been used to create thousands of production servers of the years. That doesn’t mean it’s been bug free (far from it unfortunately), it just means we’ve written Trellis with production usage in mind. It helps that one of our goals was always development/production parity.
Tagging version 1.0.0 was done for three reasons:
- we were running out of versions <= 1.0.0
- for vanity – as a signal to people that it is production ready
but most importantly:
- to act as a starting point for a better versioning scheme based on semantic versioning
Trellis versioning
Trellis is a hard project to version. It’s not a library, or an API, or even a framework. It can’t be used as a dependency or a package in a programming language either. This is partly why we’ve been bad at versioning Trellis so far. It’s been completely subjective and often forgotten.
So what will our version of semantic versioning look like? We’re keeping the concepts of major, minor, and patch versions as usual. The most important things in semver are the kinds of changes you can make: incompatible breaking changes or backwards compatible changes. We need to carry over these concepts to Trellis in a way that makes sense and here’s what we think makes sense:
- a backwards compatible change means you can re-provision a server without any breaking changes
- a breaking change means a re-provision make break something and require extra steps or manual intervention
Breaking changes will only be knowingly be made in major versions. We will also explicit mark these changes as we have been already with a note such as [BREAKING] and likely what actions you need to take to deal with it.
Using Trellis
Up until now we’re documented and recommend people to simply git clone Trellis which means you always get the latest commit from master even though we did have tagged versions. Soon we’re going to be updating our docs and recommending people default to the latest stable release of Trellis. This can always be found from this helpful shortcut on GitHub: https://github.com/roots/trellis/releases/latest. Look for these docs coming soon.
Colin OBrien
Start the discussion on Roots Discourse