Hi Cornelis, First point, do make sure you choose a suitable open source licence for the released version. Some will prevent you from releasing the extended software as a payment (private) version.
For the management, you may want to look at the hoops that Git-for-Windows goes through to keep rebasing the Windows specific patches (arranged as a 'thicket' of feature series;-) when the upstream Git.git (Linux) releases a new version. It has a set of scripts for keeping the Windows special features (in your terms: Extended) separate from the raw (in your terms: Basic) Linux version. A lot of the issues that GfW has will simply disappear for you because the 'incompatibilities' are not in the foundation layer. The other approach is to look at the real Git.git method for keeping the new feature developments under control. It has a 'master' branch (which would match your Basic released version) and then has a 'next' branch (on top of master) which contains the (effectively approved) 'Extended' version. There is then a further 'pu' (potential updates) branch that merges all te various feature branches that the devs are trying out.(that for you would become part of the extended version). Again there are a slightly simpler set of scripts to manage the introduction and transfer of the features from the Dev to Extended to Basic [using your terms] releases. It also has maintenance branches should fixes need passing dow to older versions via cherry-pick etc. Hope that helps. On Monday, January 21, 2019 at 11:57:19 PM UTC, Cornelis Bockemühl wrote: > > Right now I have a software project in a single local git repository that > I can build in two variants: > > - Basic > - Extended > > The Extended is "more" than the Basic, so there are files in Extended that > are not in Basic. But of course there are also some files that are > different for the two versions, like having less "includes" for the Basic > version etc. All this I manage right now with a variable: > "EXTENDED_VARIANT" switches everywhere to that version, and if it is not > set the "Basic" will be built. > > With this I can manage one single code base for the two variants of the > software. So far so good. > > But now I want to make the "Basic" version "Open Source", but keep the > "Extended" version for paying customers only. And this means I should > somehow split the repository in two: > > - an Open Source repository with public access for the "Basic" variant > - some kind of "extension repository" that I keep local or in a protected > location > > To some degree I could manage the two variants with a permanent branch > where I "merge" from time to time the "basic" branch into the "extended". > However I am afraid that this will permanently generate conflicts in some > files that are not really conflicts. And both branches will probably have > to reside in the same repository. > > I can also have a project that brings together two different repositories > - basic and extended - from two different sources. But then I am getting > problems with the files that need to be different in the one and the other > variant: I would have to keep two versions of these files next to each > other synchronized - not what you really want if you have git. > > The problem is that I am still relatively new to git, so there might be > options that I am not aware of! > > If this is the case I would be very glad if somebody could give me a hint. > > Otherwise, if what I want is impossible with git, I would also like to > learn. > > So many thanks for helpful remarks and hints in any case! > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
