Suggest not committing vendor directory in master, but having a dist branch to simplify development

[AndrewFeeney]

It seems to me that those wishing to install and use this project are more likely to be people for whom composer will not be a difficulty, whereas everyone who works on development will be inconvenienced by commiting the vendor directory.

I suggest one of two options

1. Commiting vendor in a separate dist branch specifically for those who want to download a ready to go build (i.e. shared hosting users etc.)

OR

2. Moving development to a develop branch in which vendor is not committed and running an automated build process upon merge into master branch to resolve dependencies and commit them to master.

[freescout-helpdesk]

Agreed. Option 2 seems to be a better solution:

1. We will create an extra develop branch and add /vendor directory to .gitignore in it.
2. Contributors will use develop branch.
3. master branch will continue having /vendor directory committed, it will be the default branch that people see when they visit project's Github page and download a ready to go build.

[dryabov]

Another alternative is to move vendor into a submodule, but I've never tried it previously.

[freescout-helpdesk]

GitHub flow recommends using branch called master as the base for forks.
So if we go with the option 1:

1. We will create an extra dist branch and make it default, /vendor directory will be committed in this branch. It will be the default branch that people see when they visit project's Github page and download a ready to go build.
2. Contributors will continue using master branch, where /vendor will be added to .gitignore

This seems to be a more natural workflow.

[freescout-helpdesk]

Another alternative is to move vendor into a submodule, but I've never tried it previously.

Moving vendor into submodule most likely will make contribution process more difficult.

[AndrewFeeney]

GitHub flow recommends using branch called master as the base for forks.
So if we go with the option 1:

1. We will create an extra dist branch and make it default, /vendor directory will be committed in this branch. It will be the default branch that people see when they visit project's Github page and download a ready to go build.
2. Contributors will continue using master branch, where /vendor will be added to .gitignore

This seems to be a more natural workflow.

Sounds like a good plan.

[freescout-helpdesk]

Done. Development guide has been updated.

Now contributors need to do:

git pull
composer install

[freescout-helpdesk]

composer.lock file currently is not committed. It does make sense to commit it. It would allow to quickly install dependencies with composer install when switching between branches. It should not make any difficulties for developers: composer.lock just will need to be committed every time composer.json is changed.

@WebSpanner what do you think?

[AndrewFeeney]

Yes, I think it's appropriate to commit the lock file.