If you have been watching Tsugi-php and tsugi lately, you have seen the pace of commits slowing down. This is good because ultimately Tsugi wants to be a library that just works. But a few recent efforts like improving blob support and activity tracking took a lot of effort and a lot of commits. But that code is now solid and has been in production for a while at scale.
The Tsugi release approach is that you run master and in a periodic cron (for me it is hourly) do a “git pull” and run upgrade.php. Master needs to always be production ready and all my production servers run master within an hour of a commit. While many of you may not be this aggressive (and don’t need to be) – I do this so I know if something goes wrong almost instantly. We are working on better unit tests and post-commit hook functionality tests to make this strategy even safer.
But with this as approach, the way releases work is more to do with freezing master at a very safe place so that we can try something in master. That way if something goes awry in master – you just jump back to a safe place. Kind of like mountain climbing with a lead climber. Always have a place to fall back to.
I will be making a change in master that I expect will be safe, but just to be sure, I want to make the 0.5.0 release / branch to come back to.
Some of you have noticed that I have frozen various versions of dependencies in composer.json:
I did this because I did not want to update a dependency and mix it with a change I was making as we went along the path. This way I did not make my change and update a dependency in the same breath so I *know* if something broken is my fault or a dependency failure / regression. Dependencies are software too – and can make make mistakes in minor releases. I conside my own QA to be QAing both all of tsugi plus its dependencies.
So what I will do as soon as I make the 0.5.0 release is update composer.json to let the dependency versions upgrade. I will do this in a series of steps to allow for some QA/production experience at each step.
I will try to make no changes in tsugi-php or tsugi during this time unless a bug appears or a dependency upgrade breaks something.
What you will see is a series of updates that update a *lot* of files – all in the vendor folder. It is OK.