Standardize naming convention of phar files in releases

[shivammathur]

It would be easier to move support for phpcs and phpcbf in setup-php to this repository if the naming of the phar files in the releases follows a convention across all releases.

Currently, the files in the latest release 3.8.0 do not have version numbers, while the files in the older releases do.

[jrfnl]

@shivammathur Yes, I was wondering about that and still meant to contact you about what would make it easier to support (well, I was about to contact you at the beginning of December, when I saw you had already made a commit for the repo address change, so I wasn't sure it was still needed 😉).

For the record: when I recreated the releases for the 2.0 - 3.7.2 versions (which were released before I took over the repo), I uploaded the PHAR files to those releases with file names including the version number (mostly for my own sanity while recreating the releases).

More than anything, I wanted to make sure that the releases would be available and available in a predictable location.

PHAR files for releases, including new releases like the 3.8.0 release, are available in the following places with the following naming conventions:

Type	Location	Available releases	Naming Convention
Permalink to latest release	https://phars.phpcodesniffer.com	latest only	No version number, phpcs.phar and phpcbf.phar
PHIVE release location	https://phars.phpcodesniffer.com/phars	3.2.0 - latest	With version number, phpcs-3.8.0.phar etc
GitHub release page	https://github.com/PHPCSStandards/PHP_CodeSniffer/releases	2.0.0 - latest	2.0.0 - 3.7.2 with version nr, 3.8.0 and later without

The reason I did not include the version number in the GH release uploads for the 3.8.0 release was to allow for another type of permalink, which would again always get the latest release: https://github.com/USER/PROJECT/releases/latest/download/package.phar.
This means that https://github.com/PHPCSStandards/PHP_CodeSniffer/releases/latest/download/phpcs.phar and https://github.com/PHPCSStandards/PHP_CodeSniffer/releases/latest/download/phpcbf.phar also work to always get the latest release.

Uploading the PHAR files on new releases (only) with version numbers in the filenames would block the use of those GH native permalinks.

I am perfectly happy to upload both with and without version number to GH releases, but I can also imagine that one of the other download locations may suit the needs of setup-php just as well ?

Let me know your thoughts on this and I'm happy to accommodate.

[jrfnl]

Note to self: might also be a good idea to add the above table to the installation page in the Wiki.

[shivammathur]

Hi @jrfnl

For the next release, unless you upload versioned files to 3.8.0, it would mean that till 3.7.2 we have versioned ones, and 3.8.0, and afterward we have unversioned ones.

In terms of implementation in setup-php, if the latest release has versioned files then it would have to get the version first to download the file. Files without versions in the latest release are good as they can be directly downloaded using the latest URL scheme of GitHub releases.

So I prefer unversioned files as well, but as you mentioned maintaining versioned ones was easier. I would leave the decision to you, it would help if it is consistent across releases. Uploading both types of files to all releases would also work and make it consistent if it is not too much work. In my experience using gh release for this helps.

[jrfnl]

For the next release, unless you upload versioned files to 3.8.0, it would mean that till 3.7.2 we have versioned ones, and 3.8.0, and afterward we have unversioned ones.

Correct (for the GH releases download location).

Files without versions in the latest release are good as they can be directly downloaded using the latest URL scheme of GitHub releases.

Well, that was my intention to use going forward.

So I prefer unversioned files as well, but as you mentioned maintaining versioned ones was easier.

I'm not saying versioned ones is easier, it only was for uploading the historic files.

And no, I have no intention of updating the old releases to add unversioned files as well, as it would mean copying four files for each release to a temp location, renaming them there to be unversioned, then uploading to the right release and deleting the local copies, rinse & repeat 56 times. I have better things to do with my time.

[shivammathur]

Yes, I understand.

Can we add the versioned ones to 3.8.0 and new releases moving forward, that would also work.