Discussion about version suffixes

[Maks3w]

IMHO any alphanumeric sufix should be recognized as part of package version.

For example I will use X.Y.Z-MN where NM is a code that indicate the symfony branch used for reference. I think that is usefull if in the future I will release parallel versions for SF 2.0 y SF 2.1 maintaining similar features.

Also could be used to show PC architecture or any other data. For example i386, nginx, apache, windows, unix, etc.

[stof]

Please discuss it on composer. Packagist is not responsible for parsing versions

[Seldaek]

You can just "require": {"symfony/framework-bundle": "2.0.*"}. That indicates just fine that the bundle is made for 2.0. Even better it will enforce it. Sorry but I don't think version strings should have that kind of information mingled in them.

[Maks3w]

@Seldaek Sorry but I'm lost with this. So if I have a version for SF 2.0 and
other for SF 2.1 then both versions can share exactly the same version
number Ex: v1.0.0
That will produce an nondeterminist situation when someone will add the
package into his composer

require": {"vendor/test-bundle": "v1.0.0"} What version will retrieve, the
version for SF 2.0 or the version for SF 2.1?

Maybe the correct way for naming will be v1.0.0 for SF2.0 and v2.0.0 for
SF2.1

I found this guidelines for PEAR packages
http://pear.php.net/group/docs/20040226-vn.php This are correct for packagist?

[stof]

@Maks3w They cannot share the same version number if the code is different.

[Seldaek]

@Maks3w The point is, you should have a version of your bundle for Symfony2.0, that requires 2.0., and if it supports 2.1. as well you can require >=2.0,<2.2. If your bundle at some point has to break compatibility, then you should do a new major release of your bundle, that only supports 2.1.*. And you should have a 1.0 branch of your bundle to still provide patches to the 2.0.* version.