Timeline for Maintaining Two Separate Software Versions From the Same Codebase in Version Control
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 12, 2014 at 10:51 | comment | added | Frames Catherine White | please don't use the C Preprocessor as a general purpose text processor. Something like GPP is more appropriate (en.nothingisreal.com/wiki/GPP) | |
| Jun 12, 2014 at 0:03 | comment | added | Joseph Leedy | @Zack, that is what tags are for. I typically have a develop branch, off of which I create feature branches. When a feature is completed, it is merged back to develop. When all code in develop has been thoroughly tested and is ready for production use, develop is merged into master. When a release is ready, a tag is created (ex. 1.0.0) from master. This workflow is based off of the excellent Driessen branching model. | |
| Jun 11, 2014 at 17:49 | comment | added | Greg Hewgill | @Zack: Yes, release branches are also fine (I've updated my answer). Thanks for pointing that out. | |
| Jun 11, 2014 at 17:48 | history | edited | Greg Hewgill | CC BY-SA 3.0 | added 135 characters in body |
| Jun 11, 2014 at 15:43 | comment | added | Zack | @GregHewgill what about keeping old versions of releases in source control? We currently have an "Active" folder, and when we get to a major release, we will create a version numbered folder for it and branch the "Active" folder to that version folder, so that version will always be the same, and we just keep working in the "Active" folder for all changes and updates. Is this an inappropriate use of branching, since there is no chance that we will ever, for example, merge the 1.2 version back into the "Active" version of the code base? | |
| Jun 11, 2014 at 4:29 | comment | added | Doc Brown | @Joseph: and since you mentioned TDD: I guess the unit tests for your premium version are a superset of the ones for your basic version, so I guess your script can filter also the "basic" unit tests out, if you think that's necessary. | |
| Jun 11, 2014 at 4:23 | comment | added | Doc Brown | @Joseph: using two repos is only appropriate if the versioning of the two code bases is almost independent from each other. If that is not the case, I would strongly recommend to do what Greg wrote and keep everything in one repo. The only thing I would rethink is the use of the "C preprocessor". I guess a small script written in the language of your choice (PHP itself is fine, Perl or Python even better) which makes a copy of your code without the (somehwhat marked) premium features would do the trick. | |
| Jun 11, 2014 at 4:09 | comment | added | Greg Hewgill | Ah I see, that would be more like the "plugin" model, where your basic code has the ability to load and run plugins (if they exist). The plugin code is separate and provides the premium features. | |
| Jun 11, 2014 at 4:07 | comment | added | Joseph Leedy | The point of the second repo is to house just the extra code - not another copy of the whole app. | |
| Jun 11, 2014 at 4:06 | comment | added | Greg Hewgill | Creating another repository is even worse than creating branches! You definitely want to choose a solution that involves the least duplication of versioned code. | |
| Jun 11, 2014 at 4:04 | comment | added | Joseph Leedy | What you are saying about branches makes total sense! Perhaps instead I could create a separate repo containing just the Premium code and use some sort of release script or a sub-module to combine it with the base code? This might make TDD harder, though... | |
| Jun 11, 2014 at 3:53 | history | answered | Greg Hewgill | CC BY-SA 3.0 |