Beyond 2.8 - some design thoughts

[Geert Janssens]

While we're working hard to get 2.8 ready for official release, the current 
state of the code keeps reminding me of a few design related topics I would 
like to discuss for the development cycle after 2.8 has been released.

We're still a few months away from that point, but it's a quiet Christmas eve 
so I am feeling like sharing this already for further discussion.

1. Use of namespaces.

Our current code is full of Gnc<some-name> for types and gnc_<something-else> 
for functions. In our C++ rewrite we're replacing this with classes of type 
Gnc<something> and so on. I would like to propose we introduce a 'gnc' 
namespace (at least in libgnucash) so our classes become gnc::<something>. 
This is consistent with std:: and boost:: namespaces.

We can debate whether our internal code can/should have "namespace gnc;" in 
headers only or in source files as well. For libgnucash I'd go for the latter. 
It  The context should be clear there. In the gnucash gui related code (the 
parts that are C++ obviously), I would as well, though I have a less strong 
opinion there.

For 2.8 I have been working on converting parts of the CSV importer to C++. 
And considering the class structure that is slowly forming there (still in 
flux as conversion of additional importers reveals design limitations that 
shouldn't be there) I am even tempted to use nested namespaces there (not 
nested classes, mind you) like
namespace gnc
{
....
namespace import
....
class settings
...

}
}

I personally like the granularity and grouping effect this has. In addition it 
makes the actual actions related to a namespace stand out nicely
gnc::import::settings::get_presets()
Which with a 'using gis = gnc::import::settings' could be reduced to 
'gis::get_presets()' if one likes.

On the other hand I don't have much experience with namespaces yet (other than 
using st:: and boost:: which have nested namespaces as well) so I don't know 
the pro's and con's of it. So I'm interested in opinions about this.


2. Versioning.

We currently use a version scheme gigantic.major.minor[-build]. Like 2.6.19 
(and an optional -2 if we had to release more than once to get it right). For 
the 3 levels we really only use two. The 2 in front has been updated when 
gnucash migrated from gtk to gtk2.  We will migrate to gtk3 for gnucash 2.8 
yet we don't changed to 3.0 as a result. The migration to gtk2 has been a long 
time ago and the software world has evolved since then. Release cycles in 
general have shortened. Incremental changes are usually preferred over big 
bang changes. So I think our numbering scheme is in for a modernization.

Here's my proposal:
After the 2.8 lifecycle let's drop one number and stick with major.minor[-
build] instead. 
Major releases would increment the first number. Bugfix releases the second.

So after 2.8 the next major release would be 3.0, bugfix releases for that 
major release would become 3.1, 3.2, 3.4...

I would drop the idea of odd numbers being development snapshots and even 
numbers being stable ones. Instead I see several options, I haven't decided 
which one is most elegant/kludgy:

Option A: let's number development snapshots starting from x.90. That gives us 
10 development snapshots. If that's not enough we can either choose to start a 
bit earlier, like x.80 or from x.98 jump to x.980 to give us 20 more.
Option B: as a variation all development snapshots do use a 3 number version: 
x.99.z with 99 clearly indicating "right before the next major release" and z 
incrementing with each snapshot.

This makes development snapshots slightly more verbose in their numbering but 
gives us cleanly incrementing stable releases. The latter are more visible to 
most users, so I personally care more about those.

The development snapshots between 2.8 and 3.0 fall a bit in between. We could 
choose to handle them old style or new style as we see fit. Old style would 
mean we'd still work with a 2.9.x series. New style would mean we'd start with 
2.8.90/2.8.99.1 as we see fit.

Thoughts ?


Other than that,

Merry Christmas to all!

Geert