rlktradewright
commented
9 years ago I need to rethink the above. The problem with it is that because the binaries are not pushed to the repository, it's not possible to recreate the full environment for an earlier build. For example, if it's necessary to fix a bug in or add a feature to a version that is not binary compatible with the current version, it's not simple to ensure all the correct binaries are in the right places to guarantee the right type library ids and class ids are carried forward in the fixed version.
Therefore we will now push dll's, ocx's and exe's.
To address the scenario above, suppose the current release is v4.1.124, and the previous release is v4.0.107. The developer must create a branch starting at version 4.0.107 to reconstruct the full file structure at that version for proper rebuilding: this new branch could be called v4.0 . Once the necessary changes have been made to this branch, it will not be sensible to merge it back into Master (which has moved way on), and the branch will have to remain permanently. A new release can then be created on that branch, which could be tagged v4.0.107a. Similarly another round of fixes could be released as v4.0.107b, and so on..
I want to get to a point where someone who wants to work with the source code (eg debug it or enhance it) can clone the repo, then build it using the scripts in the Build folder without having to mess around to much, and end up with the same type library ids, interface ids, and class ids as the latest version committed here (for example so that the included sample apps can be run without having to rebuild everything).
For this to happen, the developer needs to be able to get the current versions of the binaries into his Bin folder, so that binary compatibility (or at least project compatibility) can be preserved when building his versions.
However it would not be good to include the binaries directly in the repo, because that would cause problems when a developer submits a pull request, since they'd have to deliberately exclude the binaries in their commits - which would be error prone. Much better to exclude all binaries using .gitignore (which is the current state of affairs).
So to achieve what we want, I will build the 'official' binaries, which will determine the 'official' type library, interface, and class ids. After each such build, I will create a new release that contains a .zip file and a Windows Installer (.msi) file:
If the developer subsequently modifies any of the components in a way that potentially affects compatibility, they may end up with class ids that don't match the 'official' ones. Provided this development is private (ie not promulgated outside the developer's system), this is fine. If the developer submits their enhancements for inclusion in the main repo, and they are pulled in (resulting in a new release), this will result in different ids from what they already had from their own build, so they will need to once more download the released binaries and rebuild their local version to ensure they have all the correct ids.
I currently intend to include the Visual Studio 2008 project for building the .msi and .msm files, but I may change my mind...