On Sun, Dec 24, 2017 at 11:34 AM, Geert Janssens <geert.gnuc...@kobaltwit.be
> wrote:
> 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
>
Thank you for this thoughtfulness. I don't have any strong thoughts about
namespaces. I think that the namespace, "gnc", is a great idea, and only
adding more (nested or otherwise) as necessary would be the right way to
go. I can't think of any reason that more would be necessary, but as long
as things are done thoughtfully I don't really care much about this.
Concerning the versioning scheme: I agree that the leading "2" is rather
superfluous at this point; if we're not going to use it, get rid of it. I
*do* appreciate the even/odd versioning scheme. It has a few strong points:
1) it's easy at a glance to tell which version is stable and 2) it's easy
to explain and use.
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
