[Flow] Commit the composer.lock file or not?

[Thomas Maroschik]

Hey Guys,

I would suggest committing the composer.lock file only to branches and tags. This way the branches are kept stable and master can use bleeding edge. In the composer file version ranges have to be defined as working with a foreign projects master is imho a no go. There could be trouble if someone reviewed a change, everything worked out well and some time later someone else reviews it too and updated dependencies cause trouble. But imho this shouldn't occur that often as other projects commit too to semantical versioning and we will always define some version boundaries on core dependencies.

Regarding Jigals Questions:

Version
-------

See above. Bleeding edge development occurs on master until feature freeze. Upon feature freeze master should be branched and a composer.lock file should be committed.

Location
--------

Due to the nature of distributed systems we gain something at a price. The one thing is that we don't need to host the packages ourself if we trust the endpoints. For untrusted endpoints we could mirror the packages easily on our git infrastructure. Mirroring git repositories is not a big deal. Afaik you can define alternative locations for packages in your composer manifest. But as composer is a developer tool, I don't think we have to bother much about this.

Offline / restricted access use
-------------------------------

Composer will and can never replace the distribution and packaging process. This means dependencies will be part of the distributions as they are now with TER extensions too. Online access is just a requirement during development. And your development machine should really have online access from time to time.

Composer is something that helps us during development not during deployment. And it has several benefits for us:
* It replaces our legacy package/extension mechanism and in cms mainly legacy code
* It frees the resources from maintaining an own package management solution
* We can now reuse available parts of the PHP ecosystem
* We can now become a part of the PHP ecosystem that can share its reusable parts

Greetz,

Tom