Basically, I like the idea and how you wrote this section. I'm not sure if it is good to place it at the bottom of the chapter though. Doesn't it belong to the "Documentation" section? I also think that it's worth to merge this into 2.3.

@xabbuh thanks for your review! I've switched the "installation template" to a sidebar and I've used the.. raw RST directive to output the contents verbatim.

My main concern is this command:

$ composer require "<vendor>/<bundle-name>:dev-master"

Which version should we tell bundle creators to include in that command? Lots of them are including@stable right now.

@javiereguiluz I think the bundle doc should usecomposer require <package name> '~1' if they are in their 1.x version (you could go to a more precise requirement by giving a minimal minor version in the constraint, but this would be painful to maintain).
This would mean that bundles would have to update the installation doc only when they move to a new major version. But in such case, they already have to update their doc.

dev-master is even worse than@stable:

• it is also unbound
• it forbids using releases, forcing to always rely on potentially-unstable code

I think it's time to make a decision:@weaverryan@wouterj@xabbuh@stof do you think that this documentation is good enough to start sending PR to all bundles' repositories during the second DX Hackday? Or do you prefer to take more time to think more about this?

What do you think about the last change?

Original text

Use Composer to add the bundle as a new dependency of your project:    $ composer require <package-name> "~1"

Proposal

Open a command console, enter your project directory and execute thefollowing command to download the latest stable version of this bundle:    $ composer require <package-name> "~1"

@javiereguiluz You should add a note after the code block to tell authors to update the constraint according to the major version of the bundle (so that they know they should change it).
And for it to work fine, the master branch should have a branch-alias (so that the master branch can match such requirement without usingdev-master as constraint). So I would suggest adding a best practice for bundle telling they should use a branch alias (and linking tohttps://getcomposer.org/doc/articles/aliases.md)

@javiereguiluz Sorry for the delay - my eyes weren't on the docs during the hack day. I added some comments, but then I think this is ready! I also agree with@stof's comment, but I think it should be a different section or can be a different PR altogether.

There are 2 more changes that are coming (composer/composer#3096 and thebundle:install-like command), but I think we should use this and start making PR's. Then we'll just do another update later when we have these changes :).

Thanks!

Should I make any other change to this PR before merging it?

This issue is labeled asIn progress, but I don't know what is left to be done. Any clue? Thanks!

Looks fine to me. 👍

@javiereguiluz I think this is Finished. Now we will also have@xabbuh's help in properly labeling things. Once it's finished, I'm looking for those so I can merge them quickly :).

BUT, your branch is missing! Do you still have it locally? If not, I'll merge via the interface. But the internal merge tool requires your branch to be there. Let me know.

Thanks!

@weaverryan the GH tool provided by Fabien does not need the branch to be there. It gets the code from the special ref available in the symfony repo for PRs, not from the branch ref in the fork.
Are you using a different tool for the doc ?

@weaverryan I no longer have the branch locally :(

@stof, I'm using gh, and I just made sure I was on the latest version. It saysFetching javiereguiluz repository before failing when running a log onmaster..javiereguiluz/bundle_installation_instructions.

Is it possible that it doesn't grab from the docs ref when using--switch? I don't want to talk about gh here, I just want to know if I'll need to merge via the GitHub interface for this PR and if we should follow up with gh if this is a bug.

Thanks!

@weaverryan I'll make a PR shortly with the correct branch

see#4236

@weaverryan@stof there is nothing wrong with the tool you use. The branch is not available because I'm stupid and I deleted mysymfony-docs fork :(

@javiereguiluz no worries :). Stof was saying that the tool can actually fetch the missing code from a different location (similar to what the GH merge button must do behind the scenes). But we have a new PR now, so I'll merge from there.

Thanks!

@javiereguiluz github always keeps branches of PRs in the main repository, in order to always show the diff of the PR (even when the branch was removed). You can fetch that by usinggit fetch origin pull/NR/head:BRANCHNAME (where NR is the number of the PR and BRANCHNAME is the name of the branch you want to use locally).

I'm using gh, and I just made sure I was on the latest version. It saysFetching javiereguiluz repository before failing when running a log onmaster..javiereguiluz/bundle_installation_instructions

This looks weird. GH does not run such commands. Are you sure you run the code from the sensiolabs/gh repo ?

I think fabien sent the tool to ryan back in January 2014, so I don't think it's very up to date (not sure though)

well, I know for sure that Ryan has access to the git repo to get the latest version of the tool

@stof you're right - I updated locally, but was still using my old binary. So, my fault!