Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add branch alias #1

Merged
merged 1 commit into from Dec 1, 2013
Merged

Add branch alias #1

merged 1 commit into from Dec 1, 2013

Conversation

harikt
Copy link
Member

@harikt harikt commented Nov 27, 2013

No description provided.

harikt added a commit that referenced this pull request Dec 1, 2013
@harikt harikt merged commit 70c5392 into auraphp:develop-2 Dec 1, 2013
@harikt harikt deleted the composer branch December 1, 2013 16:51
"aura/di": "dev-develop-2",
"aura/includer": "dev-develop-2",
"monolog/monolog": "*"
"aura/di": "2.*@dev",
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@simensen What do you think about this addition to composer.

This represents any version of 2.X.Y .

One of the question to address is

if I add "aura/di": "2.0.*@dev", in https://github.com/auraphp/Aura.Web_Kernel/blob/develop-2/composer.json#L16

or in https://github.com/auraphp/Aura.Web_Project/blob/develop-2/composer.json#L18

the aura/di version that to be installed is the one represented in the Web_Project or Web_Kernel , and not that of Project_Kernel.

Aura.Project_Kernel depends on Aura.Di
Aura.Web_Kernel depends on Aura.Project_Kernel
Aura.Web_Project depends on Aura.Web_Kernel which in turn is dependent on Aura.Di ( but if I changed the version in Web_Project 's composer.json it should install the one defined in lower level )

Let me know if you need any information.

Thanks in advance.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a huge fan of 2.* but I guess that is up to you. :) It depends on how quickly you have new releases and how much you'll be changing between minor releases.

As to your "what should I do where" ... the short answer is that Composer will take all of the dependencies in the tree and try to resolve them.

So if you require 2.0.* in one, and 2.* in the others, it doesn't matter which projects required which, the only thing that will ever install is 2.0.* since all of the other constraints are more permissive.

In general, I'd say libraries should be more permissive and projects should be less permissive. And by projects, I mean end-user applications. So you could require 2.* across the board, but the problem comes in when you introduce something that people rely on in version 2.3.0 ... anything that depends on that functionality should change to something like >=2.3.0,<3 ...

This also assumes no BC breaks ever in 2.* ...

Anyway, it is really up to you. :) I'd say start tighter and then see how things progress. If it is 6 months to a year before you get to 2.1 releases it won't have hurt to stay at 2.0.* during that time and at that point 2.1 might be a big enough change that people will be happy to stick with 2.0.* for awhile before making the jump.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will wait to hear what @pmjones thinks. And as far as it works no issues :) .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants