Fabbot criticizes the double quotes, but they are used everywhere in the file. How should I handle this?

@xelaris ignore it outside your own code for now, until we fix it everywhere. The reason is that until recently, fabbot was not able to fix quotes. It was implemented only recently.

Thanks @stof. I fixed the unnecessary double quotes related to my change.

👍 the code looks good to me. Thanks @xelaris.

@xabbuh You are right about the number behind -dev suffix, but if I change it to (dev|beta\d*) the betaX must be converted to beta to use it for the stability argument for composer. Since I can't see any drawbacks in also matching e.g. 2.7-dev1, I wonder if it is worth to do this. What do you think?

The .* part was there because the actual version is 2.7.0-dev when looking up 2.7 and since the patch level isn't relevant IMO, I added it to be more tolerant, though (.\d{1,2})? is more accurate here, so I changed it.

Making it case-insensitive seems to be a good idea. Please have a look at the updated PR.

IMO if a new comer tries to install a dev/beta version (that he may had read in a blog or forum) with the symfony installer and see the following message with composer, he will be so confused
Why not simply write that such unstable version are not installable for the moment?

a symfony dev know how to update symfony/symfony if needed

I think it's good to propose to install the dev versions, but only on the
current dev branch, because it allows developers to automatize the
Symfony installation even with the dev branch.
A newcomer will often install the last version, because he'd have saw it on
symfony.com.
I don't think that someone would tell his followers to write something such
as symfony new project 2.7-dev in a blog or a forum presenting Symfony...

2015-04-16 11:57 GMT+02:00 Antoine Makdessi [email protected]:

IMO if a new comer tries to install a dev/beta version (that he may had
read in a blog or forum) with the symfony installer and see the following
message with composer, he will be so confused
Why not simply write that such unstable version are not installable for
the moment?

—
Reply to this email directly or view it on GitHub
#144 (comment)
.

Ok, so why talking about composer?
why not directly add the dev option that is resolved like the latest or lts in the json file? or let the installer resolve a version (e.g. 2.7 to 2.7.0-dev) and warn the developer that the version being installed is a unstable one?

You're right, we should not talk about composer as it is not used when retrieving the correct Symfony version.

@Pierstoval symfony.com does not generate pre-built archives for branches (which would require regenerating them on each commit)

So there is no "currently possible" way to install Symfony 2.7 with the installer?

I propose you the following. Instead of outputting the Composer installation instructions, which may confuse some users, we could link to the new documentation article that explains how to use and install an inestable Symfony version.

This article isn't published in the docs yet (and it hasn't even been accepted yet) but here it is: symfony/symfony-docs#5186

If there is no way to generate a package for dev/beta versions, this is far better I think

@94noni I'm afraid there is no way to generate those packages. As pointed by @stof, that would require us to generate a new package whenever a new pull request is merged.

In any case, using a inestable version is a "niche" thing with a simple alternative solution, as explained in the new doc. That's why I think there is no need to complicate things.

👍 for the docs

@javiereguiluz Would it be much overhead to build them for beta versions too? Making that possible would make it easier for people to test them and hopefully find issues before the final release.

it could be possible for beta versions IMO. these are releases after all

To sum up the above discussion, what about doing the following:

• If the user types in the name of a released beta version, the installer installs that beta version (we already have packages for beta versions: e.g. http://get.symfony.com/Symfony_Standard_Vendors_2.7.0-BETA1.zip).
• For dev versions, we don't provide packages or any way to install them, but we show the user the doc link with more information.

symfony install beta-test 2.7.0-beta1 should be good IMO 👍

@Pierstoval beware that URL is case sensitive:

// it doesn't work
$ symfony new my_project 2.7.0-beta1

// it works
$ symfony new my_project 2.7.0-BETA1

Thanks for pointing that, it's kind of important, we should then choose to strtoupper the argument then, or indicate explicitly that the beta is in uppercase 😃

So
symfony new my_project 2.7
symfony new my_project dev
are resolved and downloaded now? with the actual installer's version

@94noni nope :(

This already works (today):

$ symfony new my_project
$ symfony new my_project 2.6
$ symfony new my_project 2.7.0-BETA1

This doesn't work (today):

$ symfony new my_project 2.7
$ symfony new my_project 2.7.0-DEV
$ symfony new my_project 2.7.0-beta1

Is a PR welcome for integrating dev and 2.7 args?

@94noni I don't see a way to resolve this for dev (there is no package that could be downloaded). For 2.7, I can think of one solution: Detect that there is a beta release available and ask the user if they want to install it. We should not do this automatically imho since people usually want to install a stable version of the framework.

@xabbuh according to http://symfony.com/versions.json, "dev" => "2.7.0-BETA1" so if there is a zip ready on the server, it will be downloaded, no? (see discussion on the lts #105 (comment))
for 2.7 (or any dev/beta versions), I am ok with the proposition to ask before continuing the installation of such version

Can any branch present in the versions.json file can be considered as "installable" except dev ?

If yes, there's not much to do in the installer to allow them to be installed, just need to add a check that matches "BETA" to ensure that the "probably uninstallable" branch is effectively installable, except dev branches (that are not released, so there is not distant zipball available for dev versions).

@javiereguiluz symfony new my_project 2.7 is possible now, but installs 2.7.0-BETA1 without any information or warning. symfony new my_project 2.7.0-BETA1 doesn't work, since the version has to match /^2\.\d(?:\.\d{1,2})?$/

@94noni Although dev points to 2.7.0-BETA1 yet and this would be an installable package, it could also point to 2.8.0-dev which woudn't an installable package.

@Pierstoval e.g. the 2.8 branch, listed by versions.json now, can't be considered as installable, since it is a dev version only and there is no release yet.
It is already possible to call symfony new my_project 2.8 now, but it ends in a HTTP request to http://symfony.com/download?v=Symfony_Standard_Vendors_2.8.0-dev which isn't available and won't be available in future. The command stops with a RuntimeException in this case.

I think, regardless of the listed branches in versions.json, the actual version must be checked for -dev or -BETAX postfix, to determine the stability. If there is no postfix, it is a stable release and can be installed like before. If it is a beta release, a warning or question should be presented, as suggested by @xabbuh. If there is no release (dev version) the link to the doc should be presented instead of the composer command as suggested by @javiereguiluz.

To enable a user to specify beta versions explicitly as an argument, the validation has to be changed and the command should ensure the -betaX is converted to uppercase.
I see another issue, once a 2.7.0-BETA2 comes out. Then there is no way to determine if 2.7.0-BETA1 is a valid/installable version, since there is no occurrence in versions.json, isn't it?

The -dev versions cannot be downloaded, as they are not released, so there is no package for it. And it will probably never be downloadable, as it would need the team to generate a zipball for every commit/merge in the branch...

@Pierstoval If your last comment is related to mine... I don't said dev versions should be downloaded, do I? Actually this PR was created to prevent the installer to try to download such versions.

@xelaris thanks for proposing this feature and for sending this pull request ... and thank you all for the discussion.

I'm closing this in favor of #185, which hopefully addresses most of the raised concerns. Thanks!