Re: Beyond 2.8 - some design thoughts
Op woensdag 27 december 2017 12:51:32 CET schreef Wm via gnucash-devel: > On 24/12/2017 16:34, Geert Janssens wrote: > > [snips below, hopefully context maintained] > > > 1. Use of namespaces. > > > > 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 > > > > 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. > I'm not sure what most people consider CSV accounting data is useful to > begin with, although I also know it can't be ignored entirely. > > The ever-improvement of the csv import is a project that will always > fail, it happens every time someone exports a csv file from their > accounting program / spreadsheet and the gnc import doesn't say "hooray, > I love your format, we bow to your format". Whether it's a useful format or not is not too important. It is pretty universal though and a generic export format available in many accounting packages, including online banking sites. For that reason alone we have to support it. It comes in many variations though so it is likely some tweaking will always be necessary. What I aimed for in the new csv importer is to make fewer assumptions on what the exact format of a csv file is. The importer is now configurable with live preview. I agree we'll probably never be able to support all exotic flavors of the csv format. But if I can tip the balance from 80% of the users has to preprocess their csv file to 20% have to, that's a win for gnucash in my opinion. > I suggest a presumed import > format of ledger-cli type data and levering the work of shared open > source accounting data. Writing a script to get from a csv into > ledger-cli is transparent, portable and useful to a broad community. > A ledger-cli type data import would surely be welcome. On the other hand not all of our users would be capable of writing such a script. It would shift the burden of getting the tweak the csv file for usefulness one level up, namely to get it to convert into ledger-cli format. So there also each possible variation has to be taken into account. So in the end I don't see how this would make things easier for the end user. > > 2. Versioning. > > > > 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. > > gnc's versioning does seem dated although I expect people that read the > dev list may be used to them by now. > > As someone less involved in gnc coding but with a lot of interest in > data I'd have thought the next non-backward compatible format change > would be the next gigantic. Ok, which is more or less what my proposal achieves. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Beyond 2.8 - versioning
Op dinsdag 26 december 2017 00:36:04 CET schreef Aaron Laws: > 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. Thanks for your feedback Aaron. We are used to the even/odd scheme. There are other projects that have always used the "unstable=.99" scheme. Once you know it it's equally easy to explain, no ? If we would go to a two-number scheme for stable it would feel weird to me if the first number would distinguish between even and odd, like 3.0 is unstable and 4.0 is stable. For me that doesn't work very well. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Beyond 2.8 - some design thoughts
Op maandag 25 december 2017 01:49:41 CET schreef Alen Siljak: > To me, as an outsider and an occassional tester, Semantic Versioning would > make much more sense than any other custom versioning system. Simply > because it is getting common across various software packages and > libraries. It might work for the GUI application as well, when referring to > the workflows instead of APIs. In that regard, I would always go for the > "don't make me think" approach and stay away from numbering schemes that > require a user manual to figure out. > There's an answer on Stack Exchange that explains this into more detail: > https://softwareengineering.stackexchange.com/questions/255190/how-does-sem > antic-versioning-apply-to-programs-without-api > I do agree up to some point. I consider the scheme I propose to be mostly a simplified form of the semantic versioning. We will use one level less, because we don't distinguish between bugfixes and compatible features. I can understand why this is suggested for libraries. The reality is we haven't been doing this for years. Also with every major release (2.6.0, 2.8.0,...) we have been introducing backwards incompatible changes. According to the semantic versioning this means we should have updated the first number rather than the second one. So applying the rules of semantic versioning on gnucash in the past would have been misleading. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Beyond 2.8 - some design thoughts
On 24/12/2017 16:34, Geert Janssens wrote: [snips below, hopefully context maintained] 1. Use of namespaces. 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 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. I'm not sure what most people consider CSV accounting data is useful to begin with, although I also know it can't be ignored entirely. The ever-improvement of the csv import is a project that will always fail, it happens every time someone exports a csv file from their accounting program / spreadsheet and the gnc import doesn't say "hooray, I love your format, we bow to your format". I suggest a presumed import format of ledger-cli type data and levering the work of shared open source accounting data. Writing a script to get from a csv into ledger-cli is transparent, portable and useful to a broad community. It also means only one significant import / transfer format for gnc and related software to concentrate on <-- very good thing. 2. Versioning. 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. gnc's versioning does seem dated although I expect people that read the dev list may be used to them by now. As someone less involved in gnc coding but with a lot of interest in data I'd have thought the next non-backward compatible format change would be the next gigantic. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
