Ichthyostega
17ee3ac1cb
Starting with the upcoming ''preview release'', branches, branch names and tags will be rearranged to follow the Git-flow pattern instead of the existing ad-hoc organisation with a release branch. The documentation provided here defines the actual naming conventions and some fine points regarding the version number upgrades and placement of release tags. Furthermore, two helper-scripts are provided to automate version number updates - `buildVersion.py` : extract current version from git tag and allow to bump version - `setVersion` : manipulate all relevant files with `sed` to update the version info
52 lines
2.3 KiB
Text
52 lines
2.3 KiB
Text
Code Base Organisation
|
|
======================
|
|
|
|
//Menu: label Code Base
|
|
//Menu: prepend child CodingGuidelines
|
|
//Menu: put child LinkingStructure after CodingGuidelines
|
|
//Menu: put child GitBranching after LinkingStructure
|
|
|
|
|
|
This section of Lumiera's technical documentation deals with the code base as such,
|
|
not so much with the internals of the Lumiera application. It is targeted towards
|
|
people participating in Lumiera development.
|
|
|
|
The Lumiera source base is huge and expected to grow for some time to come. Just
|
|
judging by the _lines of code_, Lumiera can be considered as a *medium sized system*,
|
|
which gives us some hints towards the adequate practices, conventions and the
|
|
degree of formalism to apply.
|
|
|
|
Generally speaking, a *small system* doesn't exceed the mental capacity of a single
|
|
knowledgeable human. A single person can know everything and understand everything
|
|
in such a code base. Thus, any formalism and organisational overhead is detrimental;
|
|
we're best off doing away with ``Methods'' and just rely on taste and craftsmanship.
|
|
|
|
But there is a hard limit for this approach, kind of a _sonic wall_ -- usually somewhere
|
|
around a size of 60000 LoC. At that point, the adequate value system flips around as a
|
|
whole. Since beyond that point, no single person can understand and know everything about
|
|
such a system, _communication and understanding become the primary concerns_ of the
|
|
development process. Suddenly, we _do need_ some organisation, some rituals and
|
|
a methodical approach. Yet still we don't need a high degree of formalism, since
|
|
at least we can easily _know and recall everyone involved_.
|
|
|
|
To give a delineation to the other side, a constantly growing project might eventually
|
|
reach the point where the actual coding of new functionality makes up less than 25%
|
|
of the overall work required. More people might be involved than anyone can recall or
|
|
overlook reasonably. A code size of 1 Million LoC seems to exceed any kind of sufficiently
|
|
precise imagination. From that point on, a rigorously formalised organisation is vital
|
|
to keep such a *large scale project* from floundering.
|
|
|
|
////
|
|
Conventions
|
|
-----------
|
|
_to be written_
|
|
|
|
Guidelines
|
|
----------
|
|
////
|
|
|
|
''''
|
|
* also see the link:{ldoc}/devel/rfc.html[Design Process] for ongoing discussions
|
|
* see the link:/devs-vault/[Developers Vault] for frequently used developer's resources
|
|
|
|
|