Release version 1.3.3/1.4.0 and syncing the branches

[jrfnl]

Setting the scene

A couple of years back, a number of things were proposed for version 2.0 and work was started on that, but there has been little progress in the past year or so.

In practice this means that there is now one commit (#148) in master, which is not in develop (which is why Dependabot is not yet running) and - aside from the v2 specific patches - there are also a number of commits in develop which should be ported to master.

How to move forward

To make merges and releases more straight forward again, I think it would be good to get the branches back in sync and change strategies a little.

There are basically two options:

1. Keep the branches as they are and cherrypick select commits from develop to master and visa versa.
   The milestone of the cherrypicked commits should be updated from 2.0.0 to 1.3.x Next.
   This will largely keep things as they are now workflow wise, but keeps the mental overhead of the two branches potentially diverging and having to cherrypick and such.
2. Cherrypick select commits from develop to master and then rebase develop on top of master.
   This should be combined with setting the default branch back to master, rebasing currently open and viable PRs against master if they are not part of the larger changes for 2.0 and don't contain breaking changes (and switching the branch these PRs are pulled against).
   Moving forward, PRs should be pulled against master (with the exception of 2.0 specific PRs) and when PRs are merged, the master branch should be merged into the develop branch, until develop is ready for the 2.0 release.
   Note: This change does mean that people with active forks, will have to reset their develop branch.

I'd advocate for strategy 2, but would like to hear opinions.

Detailed proposal

I'd be happy to get this sorted and to put the work in to make it happen.

Independently of which workflow is used, I believe the following changes should be included in the next release/cherrypicked to master:

• Application bootstrap: fix version check #100
• GH Actions: version update for various predefined actions #109
• The bug fix from Tests: add dedicated test for the SyntaxError::translateTokens() method + edge case bug fix #117 (not the test changes)
• The bug fixes from SyntaxError::getNormalizedMessage(): improve tests + 2 bug fixes #118 (not the test changes)
• Fix typos #124
• GH Actions: fix download URL for box #125
• GH Actions: harden the workflow against PHPCS ruleset errors #128
• GH Actions: bust the cache semi-regularly #129
• GH Actions: update PHP versions in workflows #130
• GH Actions: use fail-fast with setup-php when creating the binaries #131
• GH Actions: fix up fail-fast for setup-php #132
• Align the percentage output #140
• GH Actions: update for the release of PHP 8.3 #150
• Composer: add keywords #160
• Skip shebang sequence if it is the first line #146
• PHP 8.3 + 8.4 to master branch #151
• GH Actions: update PHP version for PHAR boxing #152
• [PHP 8.4] Fixes for implicit nullability deprecation #154
• OutputTest: fix risky test #156
• GH Actions: version update for various predefined actions #158 / Various Dependabot updates which should start being pulled as soon as the change from Add dependabot configuration file #148 is merged into develop.
• GH Actions: fix duplicate release #159
• Changelog

I intend to do some test runs in the next few hours to make sure we'll have a passing build on master with the changes as proposed.

I'll also start preparing the changelog for the 1.3.x release (or 1.4.0, I'll have a look what it should be when I prepare the changelog).

@grogy What do you think ?

[jrfnl]

FYI: I've re-milestoned the above listed PRs to 1.3.x will be renaming that milestone in a moment to 1.4.0 as the release contains something which can be considered a new feature.

[jrfnl]

I've prepared a feature/release-1.4.0 branch containing the cherrypicks as proposed above + a changelog for the 1.4.0 release based on the above PRs/commits being included in the release.

The builds pass for the 1.4.0 release branch, with the exception of PHP 8.4, but this is not due to this package not being compatible, but due to Nette Tester 1.0 not being compatible with PHP 8.4.

Target release date: Tuesday March 19 (providing @grogy responds in time).

[jrfnl]

@grogy Would be great to get this out of the door and as PRs can't be merged with an approval, I can't do anything about this without you getting involved. When can we get this done ?

[jrfnl]

In the mean time, the 1.4.0 release has gone out 🎉

@grogy and me discussed the branching today in a call and the conclusion was basically that it would probably be best to work towards getting the 2.0 release tagged soonish and to then drop support for the 1.x branch.