Add a branch alias

[soullivaneuh]

You should add a 2.x branch alias.

Currently, if I do this: "cpliakas/git-wrapper": "^2.0,>2.0.0"

I get:

  Problem 1
    - The requested package cpliakas/git-wrapper ^2.0,>2.0.0 exists as cpliakas/git-wrapper[1.0.0, 1.0.0-RC1, 1.0.0beta1, 1.0.0beta2, 1.0.0beta3, 1.0.0beta4, 1.0.0beta5, 1.0.0beta6, 1.0.0beta7, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.1.1, 1.1.2, 1.2.0, 1.3.0, 1.4.0, 1.4.1, 1.5.0, 1.6.0, 1.6.1, 1.7.0, dev-master, v2.0.0] but these are rejected by your constraint.

[TomasVotruba]

That's not related to composer alias but a typo. I preffer composer require cpliakas/git-wrapper to save these troubles. Try that and let me know how it works.

Could you find the typo in your line?

[soullivaneuh]

It is not a typo issue. This package works with ^2.0 notation.

Look at this: https://packagist.org/packages/cpliakas/git-wrapper

Nothing related to 2.x branch. Having branch aliases allows composer to find which unstable branch works with the matched working version.

Example with symfony: https://packagist.org/packages/symfony/symfony#dev-master

[soullivaneuh]

With branch alias and ^2.0,>2.0.0 notation, I'll have insurance composer will fallback to a stable version when it will be release. Using dev-master will not handle that.

[soullivaneuh]

See also: https://getcomposer.org/doc/articles/aliases.md#branch-alias

[TomasVotruba]

^2.0,>=2.0.0 - what about this?

[TomasVotruba]

Which is the same as ^2.0

[soullivaneuh]

@TomasVotruba You didn't understand. I want a commit you pushed that is not yet released. When branch alias is correctly setup up, I can do some thing like this: ^2.0,>2.0.0. In this case, composer will find the 2.x-dev branch alias and will checkout master.

Later, when 2.0.1 or 2.1.0 will be released, composer will fallback to a stable release automatically.

Without branch alias, nothing like that is possible.

Note branch alias is only required for master as the 1.x branch already as the correct name.

[TomasVotruba]

I see, thank you for explaining.

What do you need this for? Using dev branch not locked to commit allows to break you code

[soullivaneuh]

What do you need this for?

As I said, a not release commit! :smile:

Currently is just to test the deprecation message with run, not a big deal. But could be a big deal if the commit is an important fix.

Using dev branch not locked to commit allows to break you code

I know that, BTW composer warn about this because this method is not possible if you don't force minimum-stability to dev. :wink:

[TomasVotruba]

For using not release commit it's better to commit lock dev version.

Branch aliases makes sense in monorepo like Symfony to test mutual dependencies before stable release and go promote dev version installs, e.g. before big release to test it out.

Since this package has no rapid development curve (all is ready and stable), it would only add maintenance cost in exchange for option that is already possible without it. I respect Occams razor in this

[TomasVotruba]

Also, composer doesn't check for invalid PHP code, which this would allow to install :)

[soullivaneuh]

AFAIK, the way I install and test my dependencies is regarding me. :wink:

Adding a branch alias is done on most all packagist repositories. It does not cost anything to add it (just clicking on a merge button BTW) and will allows more flexibility to developers to manage dependencies.

Sincerely, I don't see what is the issue here. :thinking:

[greg0ire]

@TomasVotruba it's not only for monorepos: it allows people that badly need an unreleased commit to get it while being sure they still benefit from semver (because if you do a BC-break, you will, or at least should, bump that number).

[TomasVotruba]

Propper way to do so is commit lock

[greg0ire]

It's arguable, you might not want to lock, you might want to get a commit or any subsequent commit, provided they don't break BC. Composer will warn if you use commit lock BTW, or if you use unbound version constraints like dev-master.

[TomasVotruba]

I've used branch aliases before and it adds extra maintenance cost that needs to be checked every release manually, which lead to forgotten aliases and desynchronization of version and extra PRs to fix that.

I won't bound this repository to that.

[TomasVotruba]

I understand benefits on user side. Still rather commit lock then pitfall I've described above.

[greg0ire]

I've used branch aliases before and it adds extra maintenance cost that needs to be checked every release manually, which lead to forgotten aliases and desynchronization of version and extra PRs to fix that.

That's true, but you can restrict that to only majors if you keep it vague enough (2.x-dev as opposed to 2.1.x-dev). Is that what you were previously doing?

[greg0ire]

Another alternative is to only have numbered branches (no master branch, but 1.x, 2.x, etc...)

[soullivaneuh]

I've used branch aliases before and it adds extra maintenance cost that needs to be checked every release manually

The only branch you have to update is master. Composer fallback to branch name as default.

As @greg0ire said, you might want to use 2.x-dev instead of 2.0.x-dev. You will have to update only on next major. We use this method on all sonata repositories, it works very well! Or indeed, use numbered branches only.

[TomasVotruba]

I undesrtand the technique and it's purspose for you. It don't thinks it's worth it to put my effort to maintain this.

I'm taking opinionated descission and closing this.