Do not add vendors to the Chamilo repo
I'm open this task in order to discuss this issue.
I'm ok to not adding every time the vendor folder (it is recommended not to)
But the problem here is that new developers don't know how to use composer, so we're adding one more step in order to develop with Chamilo.
What do you think? I'm adding the vendor as usual.
Updated by Yannick Warnier almost 7 years ago
I think it doesn't really matter. The initial repo is already quite heavy without the vendors dir, and these are required anyway to make the code run.
My focus is on easy inclusion of new developers and, as far as I can tell, adding steps to the setup of their own repo is an additional barrier.
Maybe within a few years, when everybody is used to it, we can remove that, but the experience with LCMS is that it is very frustrating not to have all the elements you need and not finding the documentation that explains it.
For me it is a "no" to remove the vendors dir, until at least the end of 2014.
Updated by Julio Montoya almost 7 years ago
I'm doing some merges now (between 1.10 branches) and I have a ton of vendors diffs. This problem will appear every time we have to deal with merges.
I say "yes" to not include vendors at least for development stages, but when releasing a stable version we could add a "fat" zip that includes the vendors.
Updated by Julio Montoya over 6 years ago
I'm copying the comment from the other task here:
I think we should create a new branch in github called "develop" or "dev". The "vendor" folder will be empty and all our commits will be sent there. Every serious PHP developer will use this branch and use composer properly. If other developer don't know how to use this, they could just use the master which is an stable-fat version and contains the vendors needed to install Chamilo, etc.
Then, in the "master" branch we could add the "production ready" vendor folder (with no dev crap). I think it was a good idea to use the git flow approach that Marco/Diego proposed. In our case we could start just with 2 branches "master" and "dev" all PR will be added in dev. Then we could import those changes in "master" that will be a "stable" version.
I highly recommend to see this:
Updated by Yannick Warnier over 6 years ago
Personally I don't see that we have enough resources to maintain one more branch. I highly prefer that we maintain all the vendor crap in our HEAD branch, then remove them at the time of packaging. The problem with having one more branch is that we are obviously creating more confusion, more time explaining things, etc.
The model would work if there were a clear maintainer additionally to our current development staff, but this is not the case, so as beautiful as it sounds, it just seems unrealistic to me. We are already far behind schedule for 1.9, and on having a beta for 1.10 in October.
I would rather push that away to 1.11.
I am NOT saying it is a bad idea overall, rather the contrary, but I don't think this is the adecuate moment to apply it to our processes. I see it as an additional investment in time that could potentially damage the momentum we have towards other competitor projects. We need to focus now on stability and new features. Packaging can come once it's all ready.