Committee Topic: Deployment (binaries in repo or source only)
by Scott Burns · in Torque 3D Beginner · 10/02/2012 (5:34 pm) · 7 replies
A topic the committee discussed recently is whether to change how the engine is deployed to the end user. Currently the engine has requirements for certain executables to exist in order to run correctly, thus we have the necessary executables checked in to the repo. This means each update to master that involves source changes will require those executables to be updated. Typically this is considered a bad practice, but with as often as we expect master to be updated it shouldn't be much of an issue. Keep in mind that non-programmers have to be accounted for, people who are just going to want to download it and run Torque without building it.
So the question we're posing to you all, should the repo include executables or be source only with some other kind of packaged downloads?
So the question we're posing to you all, should the repo include executables or be source only with some other kind of packaged downloads?
#2
10/03/2012 (2:40 am)
Are there ways to ignore changes to specific files using the Git executable? If there is then it should be simple to ignore the exe file changes. If not then it kind of wastes bandwidth. Not sure there is a good way to avoid that.
#3
My reasoning behind this is if you keep building the engine every master update, you'll eventually be left with a whole load of engine binaries for outdated versions in the repository which will make it an increasingly bigger PITA to clone.
10/03/2012 (2:44 am)
Keep binaries out of the source repo (except where needed for building), offer compiled SDK downloads for major releases perhaps deployed via some automated process (similar to, say, OGRE).My reasoning behind this is if you keep building the engine every master update, you'll eventually be left with a whole load of engine binaries for outdated versions in the repository which will make it an increasingly bigger PITA to clone.
#4
10/03/2012 (8:27 am)
Masters should be source code only. The documentation to compile the engine is so very clear that even "curious george" could do it.
#5
Someone using the development branch should be knowledgeable enough to handle things on their own.
What would be preferable would be downloadable packages of the "official" stable versions.... someone using version control should be knowledgeable enough to handle compilation of binaries on their own ;)
10/03/2012 (11:53 am)
At most let the master branch contain the necessary binaries. That way the less developer-centric users can fork/download and go with the "official" stable version.Someone using the development branch should be knowledgeable enough to handle things on their own.
What would be preferable would be downloadable packages of the "official" stable versions.... someone using version control should be knowledgeable enough to handle compilation of binaries on their own ;)
#6
10/03/2012 (1:20 pm)
I agree with James - there should be some automated way to download compiled versions that don't need to include all the source code. The repository should be just for the source code, and minimal on the art, to make it a lighter download.
#7
If you're checking out from GitHub you're also on the bleeding edge, and then you should be capable of compiling on your own. Binaries would be unnecessary for that crowd. The users who need binaries should have a blessed package with just the binaries and scripts, made from known stable builds.
10/03/2012 (1:37 pm)
Git has terrible bloat once you have made a number of commits. The .git directory will be many times the size of the actual source, and it's hell to prune if even possible. Binaries would just complicate it (binaries, static libraries are the main cause of unfixable bloat).If you're checking out from GitHub you're also on the bleeding edge, and then you should be capable of compiling on your own. Binaries would be unnecessary for that crowd. The users who need binaries should have a blessed package with just the binaries and scripts, made from known stable builds.
Torque Owner Stefan Lundmark