37

I've recently come across the change in composer meaning that the default minimum-stability is stable, and rather than set this to dev I'd like to mark some of my libraries as stable.

I actually use two relevant branches, release and dev branched from master. Every so often something is merged into release and tagged as new version.

How does composer determine the stability of my libraries, is there a naming convention for branches, version nums, a key in composer.json?

Thanks

Rubens Mariuzzo
  • 28,358
  • 27
  • 121
  • 148
Adam
  • 5,091
  • 5
  • 32
  • 49

4 Answers4

35

The answer is: Tags. Your may also use Alias, if you don't want to use tags. But it's worth to mention, that you should only mark your packages as stable, when they are stable and not to make others believe they are.

Update: One more link: Stability

shaedrich
  • 5,457
  • 3
  • 26
  • 42
KingCrunch
  • 128,817
  • 21
  • 151
  • 173
  • 2
    I knew I'd seen that somewhere. So anything without suffix for RC, beta, alpha or patch is stable, even 0.0.x? – Adam Jul 25 '12 at 14:33
  • 8
    Correct. Anything that has a tagged release, including 0.0.x, is considered stable. – igorw Jul 25 '12 at 18:55
  • 3
    The words `stable` or `stability` do not appear anywhere in the tags or aliases links. Maybe they did at some point. – Ben Creasy Mar 03 '16 at 21:28
  • 2
    I'd point out that by _tags_, you need _VCS tags_ as in _git tags_. I thought there was some `tags` entry in the `composer.json` file to set up somewhere, but all I needed to do is `git tag -a x.y.z` and `git push --tags`. Then on the consumer project, `composer require xxx/yyy` worked like a charm. – Benoit Duffez Nov 13 '18 at 09:01
  • 2
    great example of why linking from SO is discouraged – lewis May 07 '20 at 10:05
  • As there is a reference to a link which no more works, I try to concretize that really nothing much more is necessary than creating a tag~=release in a github interface, being connected to a packagist account or having a github hook setup the changes should be reflected in a matter of a minute. Though some cached libraries might be needed to be removed from vendor or might be cached in composer.lock, so refresh it by a remove command or remove manually some as non stable download also a .git directory which troubles to be removed sometimes. Thought confirm by a remove command just after. – FantomX1 Jul 15 '20 at 13:58
  • Repository type path needs to have a version defined in the composer file in order to have version available, it does not somehow figure it out from the "local" git tags alone. And the library must not exist on the packagist. – FantomX1 Jul 15 '20 at 14:46
4

Elaborating on KingCrunch's answer, since this was not immediately obvious to me.

From https://getcomposer.org/doc/02-libraries.md#specifying-the-version

When you publish your package on Packagist, it is able to infer the version from the VCS (git, svn, hg) information. This means you don't have to explicitly declare it.

This is very easy with Github: https://help.github.com/articles/working-with-tags/

Furthermore:

If you are creating packages by hand and really have to specify it explicitly, you can just add a version field:

{
    "version": "1.0.0" 
}
iautomation
  • 996
  • 10
  • 18
  • Just to clarify, for me the problem was that I had a package which had this "version" field specified in it's composer.json, which was causing my private package server (Toran Proxy) to ignore the tags I had added with git. – Maarten00 Jun 14 '17 at 09:23
1

To answer the question :

  • for VCS, it's dev-master
  • for packagist, it's *@stable

For more about "stabilizing" or "freezing" composer versions

Freeze Make Stable

It's sometimes useful, especially during an audit, to grab latest versions of your requirements, that's why I made a composer package that make stable all your dependencies : Composer Stable Versions (https://github.com/MaximeCulea/Composer-Stable-Versions).

Using this command, your dependencies into composer.json will be automatically be changed from:

"wpackagist-plugin/wordpress-seo":"6.2"

into:

"wpackagist-plugin/wordpress-seo":"*@stable"

Freeze Composer Versions

If afterwards you plan doing the reverse thing to grab latest versions of your composer.lock which you tested your site against, especially useful while making a site live, have a look to an other of my composer command : Composer Freeze Versions (https://github.com/MaximeCulea/Composer-Freeze-Versions).

Using this command, your dependencies into composer.json will be automatically be locked:

"wpackagist-plugin/wordpress-seo":"@stable"

into:

"wpackagist-plugin/wordpress-seo":"6.2"

Hope it helps.

Maxime Culea
  • 109
  • 7
  • Just to clarify the dev-master is an alias for a default master branch at composer (composer git...), as any version specification with a dev- prefix defines that the repository has to be cloned with a git history, whereas when the tag is specified, the files are retrieved but without the git info - https://getcomposer.org/doc/articles/versions.md#branches `If you want Composer to check out a branch instead of a tag, you need to point it to the branch using the special dev-* prefix (or sometimes suffix; see below)` – FantomX1 Jun 11 '20 at 10:19
0

If you don't get your package from a github or a similar repository, but rather for example from the local path, "path" type, you have to have the version explicitly defined in the 'composer.json' file, it won't figure it out from the local git tags. Also, such a package will be installed only if it does not exist on the packagist, github and therefore it might be needed to be temporarily renamed if it exists in the local path composer.json "name" field, to something else.

FantomX1
  • 1,577
  • 2
  • 15
  • 23