* Add newline at end of file.
* Create a uniformat in the code syntax highlighting by using the main syntax `shell` instead of the alias `bash`/`sh`.
* Added (of corrected) the missing code syntax highlighting.
* Split the shell commands from the text outputs.
* Fix JSON samples formatting.
* Checked the commands and updated the text output.
Always create proxy files for package binaries,
to avoid not working binaries in case the package
was installed from a path repository and is itself linked
If the binary is a PHP script, a global variable is now exposed,
which holds the path to the vendor/autoload.php file.
This variable can the be used in the binaries to include this file
without guessing where the path to the vendor folder might be.
Additionally it is now checked on binary creation whether
the reference binary has a shebang and if not, generates
a much simple proxy code, because the stream wrapper code,
that is required for PHP <8 to omit the shebang from the output,
can be skipped.
Fixes: #10119
Co-authored-by: Jordi Boggiano <j.boggiano@seld.be>
From the Symfony Dev #french slack channel (symfony-devs.slack.com), people look confused regarding the value to use as license for proprietary projects, even though it's written in the documentation.
Because proprietary software is still a massive part of composer's usage, I think it can be interesting to have it as a note, more readable to people.
Extract from the conversation:
> J’étais sur la bonne page, il me manquait deux lignes de scroll pour voir ça -.- On a tous nos petits moments de faiblesse
Which roughly translates to:
> I was looking at the right page, just about two lines above... We all have our weak moments
They only serve to make anyone reading the docs who doesn't find
something as simple or easy as stated feel bad about themselves, they
don't add anything valuable to the docs in these cases.
You can specify a list of funding options each with a type and URL. The
type is used to specify the kind of funding or the platform through
which funding is possible.
A negative list of non-feature-branches names
is already supported - this patch adds a list of
branches names which *will* be considered as
feature branches.
Allows changing the currently hardcoded set of
expected feature branch names, from:
* master|trunk|default|develop
To any set of names or patterns that you desire.
Jeffrey Cafferata