Different versions

[harikt]

Hi guys,

First I would like to give a great applause to this great job on the badges.

I would like to ask, whether it is possible to keep badges on different branches which are different versions.

Say https://github.com/auraphp/Aura.Router/ has 2 versions.

Version 2 branch is develop-2 , and version 1 is develop branch.

Is there a way that it can fetch the branch alias from the composer.json and show accordingly the releases in the readme of two different versions ?

The idea is if someone looking at v1 readme he should understand he is looking version 1 branch and if they are looking version 2 they should understand it is version 2.

Thank you

[hpatoio]

AFAIK this is not possible at the moment. I had a first look and add this feature doesn't look as a trivial task. The UI and the way Poser scan/retrieve information from Packagist have to be modified.

[liuggio]

Hi

First I would like to give a great applause to this great job on the badges.

thanks we need this :)

Is there a way that it can fetch the branch alias from the composer.json 

it already does but:
now aura/router has this versions:

• dev-develop-2 / 2.0.x-dev
• dev-action-only
• dev-develop
• dev-master
• 1.2.0
• 2.0.0-beta1
• 1.1.1
• 1.1.0
• 1.0.0

Because starting form packagist-aura/router is not possible to understand which is the version for master and for the other branches except dev-develop2.

For me you should start naming the versions and the branches following the SemVer conventions,
or adding all the branch-alias for all the branches starting from dev-master in the composer json.

Solution A: add all the branch-alias for all the branches.
Solution B: create a branch only for the dev version eg: 1.0 and 2.0
and then creates a tag for the stable versions...

the goal is have for the latest stable: 1.2.0 and for the latest unstable 2.0-dev

and show accordingly the releases in the readme of two different versions ?

Ehm this is possible, but we could talk and vote for it, but do you still need it?

References:

• http://semver.org/

[harikt]

Hey @liuggio ,

For me you should start naming the versions and the branches following the SemVer conventions,

We are following semversioning https://github.com/auraphp/Aura.Router/releases . Not sure why you thought it is not following.

or adding all the branch-alias for all the branches starting from dev-master in the composer json.

Yes branch alias wasn't added to dev-master which is 1.0.0 . I can add it, not a big deal.

Solution A: add all the branch-alias for all the branches.

I don't know why you need branch alias for all branches.

Solution B: create a branch only for the dev version eg: 1.0 and 2.0
and then creates a tag for the stable versions...

Why the dev-master exists is it was the latest stable release of version 1 earlier. And develop was the version 1 development branch . But things have changed a lot.

the goal is have for the latest stable: 1.2.0 and for the latest unstable 2.0-dev

2.0 has released a beta, not sure whether beta don't have a badge or not .

and show accordingly the releases in the readme of two different versions ?

Ehm this is possible, but we could talk and vote for it, but do you still need it?

Sure. Looking forward.

[liuggio]

Sorry for the confusion, what I wanted to say is that if in dev-master you put the latest unstable version and you tag all the MINOR versions, and in another branch called 1.2 you put the latest dev for 1.2 and also you create a tag v1.2.0, you don't need (except for dev-master) the branch-aliasing.

My suggestion was to use tags and branches as described here: https://getcomposer.org/doc/02-libraries.md#tags and https://getcomposer.org/doc/02-libraries.md#branches,
but yes you could force with branch-alias, but is not the standard way...

[harikt]

what I wanted to say is that if in dev-master you put the latest unstable version

We have the latest stable version of 1.x in dev-master .

and you tag all the MINOR versions, and in another branch called 1.2 you put the latest dev for 1.2

the unstable for v1 is dev-develop , so yes let us think 1.2.x-dev is dev-develop.

and also you create a tag v1.2.0, you don't need (except for dev-master) the branch-aliasing

dev-master will be 1.2.0 I guess.

[harikt]

Thank you for looking into this. As there are various options mentioned I am closing the issue.

Thanks once again for your valuable time.