composer versioning

[davidverholen]

Is there a reason, why you are using the version field in the composer.json?

It's recommended, to leave it out and just use tagging.
https://getcomposer.org/doc/04-schema.md#version

You should also use a more loose version constraint in the modules, so you don't have to change them on every version update. Something like "~0" or ">=0.40".
https://getcomposer.org/doc/01-basic-usage.md#package-versions

Then you can control the installed version stability with the minimum-stability field in the root composer.json. Would be beta for now and should be stable per default after the first release.
https://getcomposer.org/doc/04-schema.md#minimum-stability

[buskamuza]

Hi @davidverholen . We're using version field to have it in a Composer package magento/magento2-base, so Satis could identify the version. Same for all composer.json files inside modules, themes, etc. This repository is a source of these packages, so its composer.json also has version field.

Also this version is currently used in Install Wizard to display Magento version being installed.

Are there any difficulties with this version field except possible human error? If yes, I think its removal can be considered - something that's not hard to do, but still requires some modifications.

[TexanHogman]

We plan to further decouple our modules by having them in separate repositories, versioned independently but we are not going to introduce this until post 2.0GA. Once we are there we will be able to loosen version constraints as well as leverage minimum-stability. However, extension developers can do that now and specify magento module dependencies like ~1.0 (actual version to be changed with our DevRC release). We have a soon to be announced backward compatibility policy based upon semantic versioning. This will minimize impacts of Magento upgrade to both merchants and developers. Additionally a set of samples are being developed to demonstrate our best practices, including this point around dependency management.

[alankent]

The final way packages are going to be hosted is dependent on parallel work going on with Magento Connect. That work is pretty early on. Having the version number present means we can package it up anyway we like. When we finalize the final approach, if we can drop the version number (by inferring from context) we can do so then. Until the final approach is finalized I am hesitant to change anything as we may be forced to change it again. Thanks for pointing this out though.

[choukalos]

Answered by Alan, Rick & Olga.