Thanks a lot for your proposals! First of all it is clear of course that the OS license needs to cover the option to "close" a derived work, but this is already the case.
Your proposal works with scripts, which is probably an option to solve the problem with the means of git. The idea that I had in the meantime is some rearrangement of the code. The idea is to really have two completely separate code bases with their own git repositories: one public, the other not. And then bring them together only with the means of CMake: - the "basic" project has some CMake configuration files that allow to build simply that version - with no reference to any "extended" version at all - the "extended" consists only of files that are not part of the "basic" version, and then it "includes" the basic sources with some kind of "subprocess call" in the CMake configuration file. I managed to also rewrite the code in such a way that only the "mainwindow" class is actually different, but the "mainwindowextended" is derived from the "mainwindowbasic" (C++ subclassing) so it inherits all the "basic" features and adds a few more. The effect is now that if I "build" the "extended" version, I get actually two exe files: "extended" and "basic" in two different folders. Which is kind of a nice side effect! >From the git point of view the two are simply two completely separate projects - which makes the management with different licenses much more simple than with "branching" and scripts - at least if you are not so familiar yet with these things. Am Mo., 18. Feb. 2019 um 19:23 Uhr schrieb Philip Oakley < [email protected]>: > 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 a topic in the > Google Groups "Git for human beings" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/git-users/D3jM7idN9nc/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Cornelis Bockemühl Basel, Schweiz -- 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.
