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.