Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
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#L16or 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_Kerneldepends onAura.DiAura.Web_Kerneldepends onAura.Project_KernelAura.Web_Projectdepends onAura.Web_Kernelwhich in turn is dependent onAura.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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :) .