a part of 3DUse current code (3DUse-core) will be diffused with an LGPL (open source) license. Yet another part of the code (including all the extensions) shall remain private (and not publicly diffused). This separation will impact on the software itself (proper headers with ownership /license mentions) but also on the engineering tools (versioning, building scripts, packaging scripts, continuous integration...) as know deployed. Realize this split and deal with its software engineering consequences.
Tasks:
[ ] assert:
which part is the core (public) and which part is the extension (political criteria/rule/designation)
[ ] tag all 3DUse (core) header files with ownership/license mentions: this is sub-issue 180
[ ] establish a version number to release and tag it.
[ ] Choose a tool among git submodule and git subtree (see technical note below)
[ ] Split the code into two (or more?) repositories
the public repository
In order for (internal) include paths to be cleared rename VCity/src/ to VCity
[ ] Portal
buy 3DUse.org domain name
create a dedicated sub-domain in LIRIS's dokuwiki (URL like liris.cnrs.fr/Vcity/3DUse)
GGE to open and transmit keys to EBO
what about mailing lists, IRC, for dealing with the community...?
[ ] Assert the impact on CI and propose an effective tool architecture and tool chain
Technical notes concerning git subtree, git submodule and other alternatives...
A classic package dependency (possibly over a devel package) is always preferable over submodules or subtrees.
Note that there is no cross-dependency between 3DUse-core and its 3DUse-extensions ! Sure the extensions has to depend on the core. But although the mainWindow GUI part of the core sends Qt signals that are/can be caught by the GUI part of the extensions (as illustrated by the call to emit activateVisuSunlightPlugin(), this doesn't represent a "hardwired" source level dependency.
The container is supposed to depend on its submodules. Within the classic sub-module didactic example, the container is the main-software and the submodules are its (static?) plugins (think of compiling the main software with all its modules being static-plugins). The advice goes: don't use git sub-module tool when the sub-module code depends on the container code. The reason is because the submodule is shared by many containters and the main reason being that container/submodule cross dependencies are hell to deal with git submodule.
What about dynamic extensions (dynamic plugins) ? Does building the plugins of 3DUse-extensions require the presence of all the 3DUse core ? Does building the plugins of 3DUse-extensions need to embark the core souce code or is it enough to use a 3DCore devel package ? Ask MTO.
Sub-modules are not a good solution when the module (3DUse-core in our case) depends on the "container" (3DUse-Extensions in our case). In other terms, the module must be independent of the container.
Motivation
a part of 3DUse current code (3DUse-core) will be diffused with an LGPL (open source) license. Yet another part of the code (including all the extensions) shall remain private (and not publicly diffused). This separation will impact on the software itself (proper headers with ownership /license mentions) but also on the engineering tools (versioning, building scripts, packaging scripts, continuous integration...) as know deployed. Realize this split and deal with its software engineering consequences.
Tasks:
Technical notes concerning git subtree, git submodule and other alternatives...
git submodule.References: