Closed Sebbo94BY closed 1 year ago
@Sebi94nbg this is all now live in pre-release as v1.2.0. We'll use v1.2.X for PHP 8.X
👌 What's the reason for the pre-release and not a normal new latest release, @ronindesign ? :D
@Sebi94nbg we need to test the refactoring changes live before we release for production. The way releases work, if I set as latest, composer will pull this new version for everyone and possibly break existing deployments, e.g. those using old versions of PHP.
Once tested for a bit, we'll move current Latest
->1.1.35
to static branch for anyone that needs to stay in an older enviornment and merge dev
->master
, update Latest
to 1.2.0
. Any issues with this plan? If you know of a way to not break existings deployments, I would be keen on that as well.
Fine for me. I only wanted to understand your release workflow. :)
Usually, you pin a specific version in your projects (e.g. 1.1.35
) or only allow a specific minor version (e.g. 1.1.*
), so that updates shouldn't break the project. So with introducing 1.2.*
, nobody should automatically get this update and break their project - in best case. In worst case, someone is always using the latest default branch code - or even dev
. 😅
I believe, it's hard to ensure, that new minor releases don't break anything. We can only avoid the most issues by having the respective PHPUnit tests for example. (By the way: We should extend the PHPUnit tests - some are defined, but do nothing.) 🙈
I personally also got rid of this default branch
and extra dev
branch. I only work with one default branch
and changes / updates get merged via pull requests into it. As soon as it's ready to release, I publish a new release. The installation and update instructions contain information about version pinning. See for example https://github.com/Sebi94nbg/teamspeak3-python-bot/blob/main/docs/UPDATE.md. This makes the development also much easier as it reduces the overhead of maintaining two branches etc.. But this is only my personal opinion. Every maintainer can do it differently. :)
@ronindesign if these changes are fine and merged, I believe, we could release a new version, which only supports PHP 8.x. What do you think? Do you take care of it?