if this is the case add the SymfonyRequirements class as sometimes is good to remove it or ignore it, same with config and check scripts 👶

I don't see why you put that comment on this line. Besides that, I'm missing what you want to say. The files listed here are things that generally should be ignored, ignoring config/check scripts is something that doesn't belong in that list imo

it is more for more slim approaches, these files change anyway depending on the OS are are files that can be cleaned up

This PR only changes the documentation to reflect the actual.gitignore. If you'd want to propose a change to the file, you should probably do it in the Symfony Standard Edition repository, not here.

I think we should make this bit a bit shorter, besides that the sentence about "parameters.yml" is wrong, you want to ignore this because this file is created from theparameters.yml.dist file.

I propose something like: "Your project folder will now contain all files of the Standard Edition, as well as all the third party code, automatically created files (e.g. logs, caches, dumped assets) and environment specific information (e.g. theparameters.yml file). You don't want to have this files included in your Git repository."

the reason to ignore parameters.yml is right. The reason why we ignore it and provide a dist file for it is indeed because it contains sensitive info (your DB password)

@wouterj that's correct, however, AFAIK the reason thatparameters.yml.dist exists in the first place is because of the sensitive information inparameters.yml that you don't want to store in git. (and also because it contains some other settings that should differ between installations of the application)

I agree that step 2 is getting a little long (in fact, it's not even a step, but merely side information). Perhaps it should be a tip (or another kind of side-content), too? Or should it be moved to another location? What do you think?

I like the explanation ofparameters.yml now, and in general, I like this explanation. I don'tthink we cover the specific reasons for ignoring these different files anywhere else in the docs.

What do you guys think about using"~2 here instead of2.4.4? I actually wish symfony.com/download did that too.

~2 means * so -1 for that However, I'm +1 for using 2.* or ~2.3

symfony.com/download is automatically updated to the latest stable version, because they want to show the latest stable version number on the download page.

no.~2 is equivalent to~2.0 or2.*. The semantic versionning operator never allows changing major version as this implies BC break.

I would use~2.3 or~2.4 in the doc. It makes sense to allow future versions, but it does not make sense to allow 2.0 while your code won't run with it

I agree that using thenext significant release constraint makes more sense than a fixed version number. However,~2 being equivalent to~2.0 is not what I understand fromthe documentation at Composer.org:

Another way of looking at it is that using~ specifies a minimum version, but allows the last digit specified to go up.

This implies to me that~2 would also allow 3.x, 4.x, etc. which is obviously not desirable. Perhaps@weaverryan and@stof are right, in which case the documentation of Composer is incorrect / outdated.

If~2 is indeed equivalent to~2.0, would that be a correct version constraint? Or should I just use~2.3 or~2.4? In that case this should be updated every time a new minor version is released...

@nicwortel I'm talking about the way~2 works, not about the way it is documented. The documentation of Composer should be improved on this point.

It would not make sense to allow bumping the major version for a next significant release operator. It would make it the same than>=2, allowing anything in the future with all BC breaks included. This is the opposite of the goal of the~ operator.

@stable is the same than*@stable, and the same than* by default (as the default minimum stability isstable). It is an unbound constraint. If you use@stable or* as requirement, your project will start using Symfony 3.0 as soon as it is released and break (because bumping to 3.0 will mean that we are not BC)

btw, try using it and validating your composer.json (with an uptodate composer). you will get a warning about being unbound (SensioLabs Insight also warns about it)

Hmm, then my vote is still for~2. This is for a new project, so I'm not convinced that the fact that this technically includes 2.0 as a problem. I think it's the best user-experience.

I also what@javiereguiluz is planning on showing people on the new symfony.com download page he's working on.

I don't. If you have a bundle doing a crap in its version constraint and the only installable version is the old version compatible with 2.0, this would automatically revert your project back to Symfony 2.0 because composer will think it is compatible, while your code is probably not.
And given the number of Symfony releases since 2.0 and the number of subpackages in it, reducing the range of versions matched at the root level makes a huge difference when running composer (both in term of speed and memory usage).
If you don't want to change it in each branch, at least use~2.3

~2.3 it is, then! However, perhaps later on we'll have to re-evaluate if~2.3 still makes sense.

extra- here onlog-