TYPO3 Core

Markus Klein wrote:

The CMS Core might be used in two ways:

• As standalone source

This is only recommended for developers.
Users should download the packaged version

• As a "library" for another composer-based project

In that case the lock file is obsolete.

The .lock file is of utmost importance, if we change dependencies in a release.
If we do not provide a .lock file this issue will occur:

• The user installs the first time using the procedure above.
• After a new release the user repeats that process (which is correct!)
• The `composer install` now fails to update the dependencies, since the existing .lock file (based on the first install) is not updated.
  (The user would need to run `composer update`, which would be wrong, since this command is intended for developer usage to get the newest updates for the dependencies.)

Imho no user would do a composer install. Besides that, we will never change composer dependencies for a released tag (obviously).
Updating TYPO3 to a version with changed dependencies means update or upgrade of TYPO3 and I think composer update (is logical there as well).
It is just a matter of documenting that.

Composer-based project

The Core is referenced as requirement in the project's composer.json and is loaded when `composer install` is run for the project.
The .lock file of the CMS Core will be ignored.
In order to ensure a stable Core, we need to ensure our .json requires only safe ranges of versions of dependencies. (we already do that)

Exactly.

In order to properly support both ways of using the Core and to further strengthen the CI environment, we should include the .lock file into the GIT repository.

In CI environments, you always checkout a clean state and do a composer install on that. This will result in the exact same state if our dependencies are pinned to a version. There is no benefit here.

(This patch should also go into 6.2 IMHO.)

I disagree. In 6.2 the recommended way to use a core checkout is to just use it. No composer install is required there at all

To sum up my view:

Pro to commit composer.lock

• A composer install is always enough to get the correct dependencies, even after a repo update
• Dev dependencies (basically phpunit) are locked to a certain version

Cons to commit composer.lock

• We need to commit an additional file into our repo, which only changes if we change the dependencies
• If we change dependencies, we need to take care to update the lock file and commit it.
• Dev dependencies (basically phpunit) are locked to a certain version - which means more work when we want regular updates

I really do not see any benefits, just (a tiny bit) more work when commiting the composer.lock file

Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/39971

Patch set 7 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/39971

Patch set 8 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/39971

Patch set 9 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at http://review.typo3.org/39971