Plenty of people have been advocating the following approach to third party code:
The actual package/library files (vendor folder) should not be part of version control, since their revisions are already handled by the declaration, which is thereby under version control and it would be redundant to do both.
This particular quote came from Ulrich Kautz in 10 pillars of modern PHP development.
I disagree with this method. My general rule is:
If it is part of your site then it should be in your version control system.
Sure, that might mean higher disk usage. But it also means fewer potential failure points. That is a trade off I can live with.
3 replies on “Version Control of Third Party Code”
Absolutely! I’ve been pushing for exactly this approach at UCD. (But no luck so far.) Yes, it takes a little bit of disk space for the compressed tarball — no need to save the source tree in version control, as far as I’m concerned. But the benefits of configuration management and system stability are *totally* worth it.
note: that link has not seemed to work for me.
But I completely agree with you. From a JEE standpoint it makes no sense not to version control it. If you have a multiple version line often some jars will not work with say a particular application server (I have clients on different ones like JBoss and WebLogic), but more importantly if you have a client that lags on a version, but needs a critical fix (and say you updated the third party software in a later version) you need that older version readily available (checkout the code to a sandbox, make the modification, commit the work, and if their is continuous integration set-up like Jenkins that’s all the work you need to do to have a verified build and ear file — not counting of course if you have specific ant properties that need to be changed.) *
* note there are some philosophies believe more in a unstable branch and stable trunk (default in Mercurial), but I found that version branches should always remain stable and ultimately prefer an unstable trunk (though sometimes you might even need to have a couple of unstable tags if you are doing R&D in different areas.) But I also believe that the trunk and branch versions should all trigger a continuous integration build. Tends to make life simpler. A side note I never liked that concept of hazing people who break the build.
Also it is important to version control DDL as well as anything that can possible change for a client(s) like archaic PL/SQL scripts (I tend to keep migration scripts in version control as well), etcetera, etcetera, etcetera.
Shawn from Riverbank/Modesto 🙂
Shawn, been awhile!
Versioning all the things is not a bad approach.