Re: [GNC-dev] Release Schedule
On May 28, 2019, at 8:06 PM, Derek Atkins wrote: >D via gnucash-devel writes: >> A custom report, as Christopher says, is a scm file. In order for it >> to run, you will have made an entry in config.user to explicitly load >> your file. >Actually, a custom .scm file could also be installed into the >standard-reports folder and will be automatically loaded. But it is >still a custom report and will need to be updated when the API changes. Well, yes, of course, but anyone who does this should be pretty clear about their file being a custom report, since it will have to be re-copied at every upgrade. The standard advice to most users is to leave the program tree intact, and use the config.user method. >> David >-derek >-- > Derek Atkins 617-623-3745 > de...@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Release Schedule
Derek, On May 28, 2019, at 8:05 PM, Derek Atkins wrote: >Wm via gnucash-devel writes: >> for example, what if someone is depending on a perceived fault in the >> current reporting system? <-- I don't know if I am doing this but I >> might be. >THIS could be an issue. One person's bug is another person's feature. >So yes, it is certainly possible that someone is depending upon the >current behavior and might be put out if that behavior changes. In fact, this already HAS happened with recent changes to transaction.scm. Changes to the settings regarding inclusion of transaction detail got changed, forcing me to go through every saved report that I had that used the transaction report as its basis (by the way, there are numerous other standard reports that behind the scenes are based on the transaction report). It was quite a surprise, and there was no warning or guidance given ahead of time. I ultimately was able to work out the problem and its solution, but it was quite frustrating at the time. David >-derek >-- > Derek Atkins 617-623-3745 > de...@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant >___ >gnucash-devel mailing list >gnucash-devel@gnucash.org >https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Release Schedule
D via gnucash-devel writes: > A custom report, as Christopher says, is a scm file. In order for it > to run, you will have made an entry in config.user to explicitly load > your file. Actually, a custom .scm file could also be installed into the standard-reports folder and will be automatically loaded. But it is still a custom report and will need to be updated when the API changes. > David -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Release Schedule
Wm via gnucash-devel writes: > On 25/05/2019 23:53, Christopher Lam wrote: >> Basically anyone who runs a custom .scm file. > > Once again you are saying custom without making it clear what you mean. I think generally here we have two terms: Custom Report and Saved Report. It's possible that sometimes the terms are not used clearly, but I feel in general Saved vs Custom is pretty clear MOST of the time. The saved report is when someone customizes their settings and saves those custom settings. This is the "saved-reports", and we DO expect this to remain across minor releases (and HOPEFULLY across major releases). On the other hand, a custom report is a new (or modified) scm file that provides new report functionality. I would certainly encourage everyone to use these terms to mean these things to improve clarity. > Some people (hopefully not too many) may have altered an .scm file > provided as part of a standard gnc installation. I think we should > presume they did that at their own risk. > > My concern is if you are proposing something else. I do not believe he is. > for example, what if someone is depending on a perceived fault in the > current reporting system? <-- I don't know if I am doing this but I > might be. THIS could be an issue. One person's bug is another person's feature. So yes, it is certainly possible that someone is depending upon the current behavior and might be put out if that behavior changes. I'm not sure how to handle this case; not all current behaviors are correct, regardless of whether they are being used. Also, some behaviors might be hard to maintain as the infrastructure changes. For example, when QOF was introduced we lost some performance because the original code could just look through selected account split-lists for matches, but there was no such ability with a generalized search. > Possibly more politics than sense, but: I am positive about gnc's > reporting being improved, I'm just not sure why we are doing more > scheme rather than more sql. Because we cannot depend on an underlying SQL source. This IS a long term goal (e.g. using an internal in-memory SQL store with external XML file storage), to always use SQL, but until we get there we cannot depend on it, and reports in SQL would disenfranchize the vast majority of users. >> Many function names are being deprecated; they are not used in main code >> anymore but custom .scm files may call them, and will error out after >> removing these functions. > > Hmmmn, OK, I still don't know what your definition of custom is :( See above. I think this is a CLEAR use of the correct (above) definition of Custom code. If you don't get it here, I think it's on you and not Chris. -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Release Schedule
On 25/05/2019 23:53, Christopher Lam wrote: Basically anyone who runs a custom .scm file. Once again you are saying custom without making it clear what you mean. For the sake of clarity, I do not think you, Christopher, are doing this with the intention of being unclear. Some people (hopefully not too many) may have altered an .scm file provided as part of a standard gnc installation. I think we should presume they did that at their own risk. My concern is if you are proposing something else. for example, what if someone is depending on a perceived fault in the current reporting system? <-- I don't know if I am doing this but I might be. Possibly more politics than sense, but: I am positive about gnc's reporting being improved, I'm just not sure why we are doing more scheme rather than more sql. Many function names are being deprecated; they are not used in main code anymore but custom .scm files may call them, and will error out after removing these functions. Hmmmn, OK, I still don't know what your definition of custom is :( -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Release Schedule
Wm, To amplify, saved-reports-x.x contains saved options settings for standard reports, and not actual custom reports.. A custom report, as Christopher says, is a scm file. In order for it to run, you will have made an entry in config.user to explicitly load your file. David On May 26, 2019, at 4:24 AM, Christopher Lam wrote: Basically anyone who runs a custom .scm file. Many function names are being deprecated; they are not used in main code anymore but custom .scm files may call them, and will error out after removing these functions. On Sat, 25 May 2019 at 21:40, Wm via gnucash-devel < gnucash-devel@gnucash.org> wrote: > On 24/05/2019 04:07, Christopher Lam wrote: > > Hi John > > My plans for 4.0 will be > > - remove *all* deprecated exported functions and deprecated code paths > > - enable book-accounting-period preference > > > > I'd urge anyone with custom reports will observe the console or > tracefile, > > and watch for any scheme deprecation warnings while running latest > versions > > of GnuCash -- old functions are due a major cleanup. If there are, please > > let us know via devel or bugzilla (and attach custom report). > > How are you defining a custom report, Chris? > > Do you mean anything anyone has in saved-reports-2.8 or similar? > > If so that is definitely non-trivial. > > -- > Wm > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Release Schedule
Basically anyone who runs a custom .scm file. Many function names are being deprecated; they are not used in main code anymore but custom .scm files may call them, and will error out after removing these functions. On Sat, 25 May 2019 at 21:40, Wm via gnucash-devel < gnucash-devel@gnucash.org> wrote: > On 24/05/2019 04:07, Christopher Lam wrote: > > Hi John > > My plans for 4.0 will be > > - remove *all* deprecated exported functions and deprecated code paths > > - enable book-accounting-period preference > > > > I'd urge anyone with custom reports will observe the console or > tracefile, > > and watch for any scheme deprecation warnings while running latest > versions > > of GnuCash -- old functions are due a major cleanup. If there are, please > > let us know via devel or bugzilla (and attach custom report). > > How are you defining a custom report, Chris? > > Do you mean anything anyone has in saved-reports-2.8 or similar? > > If so that is definitely non-trivial. > > -- > Wm > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Release Schedule
On 24/05/2019 04:07, Christopher Lam wrote: Hi John My plans for 4.0 will be - remove *all* deprecated exported functions and deprecated code paths - enable book-accounting-period preference I'd urge anyone with custom reports will observe the console or tracefile, and watch for any scheme deprecation warnings while running latest versions of GnuCash -- old functions are due a major cleanup. If there are, please let us know via devel or bugzilla (and attach custom report). How are you defining a custom report, Chris? Do you mean anything anyone has in saved-reports-2.8 or similar? If so that is definitely non-trivial. -- Wm ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Release Schedule
Op vrijdag 24 mei 2019 15:58:19 CEST schreef Geert Janssens: > Op vrijdag 24 mei 2019 15:17:59 CEST schreef Robert Fewell: > > I'm OK with the first option but suggest instead of December with all the > > diversions for Christmas it be the end of January. > > Has it been decided on a minimum Gtk version for master, there are > > probably > > some conditional version statements that can be removed and some CSS that > > I > > want to change/rename. > > According to repology Ubuntu 16.04 ships 3.18.9. That's one of the LTS > distros we care to support and with that probably the oldest Gtk release we > have to support. > > Linux Mint has even older versions according to that same website, but they > only list Linux Mint 17.x. The linux mint website itself suggests that is no > longer supported. The oldest supported version is either 18, which is based > on Ubuntu 16.04) or 3 (based on Debian Stretch). According to the above > Ubuntu 16.04 ships Gtk 3.18, Debian stretch ships 3.22. > > And even Centos 7 ships Gtk 3.22 :) > > So it looks our baseline for gnucash 4.x will be 3.18. > That will allow you to at least drop the conditionals for 3.12 and 3.14. > > Regards, > > Geert In addition it would have been great to raise the minimum version of guile to 2.0.10 to eliminate all the conditionals on the availability of srfi-64. Unfortunately RHEL7/CentOS7 only ships with guile 2.0.9 :( The same goes for openSUSE Leap 42.3. However support for that release ends June 30 2019, so I don't think we have to take that one into account for our December/January release. On the other hand RHEL8 ships with 2.0.14 (and hence CentOS7 will also) so it's tempting to drop CentOS7 support... Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Release Schedule
Op vrijdag 24 mei 2019 15:17:59 CEST schreef Robert Fewell: > I'm OK with the first option but suggest instead of December with all the > diversions for Christmas it be the end of January. > Has it been decided on a minimum Gtk version for master, there are probably > some conditional version statements that can be removed and some CSS that I > want to change/rename. According to repology Ubuntu 16.04 ships 3.18.9. That's one of the LTS distros we care to support and with that probably the oldest Gtk release we have to support. Linux Mint has even older versions according to that same website, but they only list Linux Mint 17.x. The linux mint website itself suggests that is no longer supported. The oldest supported version is either 18, which is based on Ubuntu 16.04) or 3 (based on Debian Stretch). According to the above Ubuntu 16.04 ships Gtk 3.18, Debian stretch ships 3.22. And even Centos 7 ships Gtk 3.22 :) So it looks our baseline for gnucash 4.x will be 3.18. That will allow you to at least drop the conditionals for 3.12 and 3.14. Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Release Schedule
I'm OK with the first option but suggest instead of December with all the diversions for Christmas it be the end of January. Has it been decided on a minimum Gtk version for master, there are probably some conditional version statements that can be removed and some CSS that I want to change/rename. Regards, Bob On Fri, 24 May 2019 at 12:37, Christopher Lam wrote: > Oh and also: > > I'll wish to transition *all* html-acct-table based reports to force them > to do subtotals properly. > > There are currently 9 different combinations for subtotals while displaying > accounts, depending on the Display settings "parent account balances" and > "parent account subtotals"; the 'canonically-tabbed' option should be > deprecated; and either parent account include children-account subtotals, > or parent subtotals displayed after their children group. i.e. 9 > combinations reduced to 2 options. > > I'll hope this can be achieved for 4.0. > > > On Fri, 24 May 2019 at 03:07, Christopher Lam > wrote: > > > Hi John > > My plans for 4.0 will be > > - remove *all* deprecated exported functions and deprecated code paths > > - enable book-accounting-period preference > > > > I'd urge anyone with custom reports will observe the console or > tracefile, > > and watch for any scheme deprecation warnings while running latest > versions > > of GnuCash -- old functions are due a major cleanup. If there are, please > > let us know via devel or bugzilla (and attach custom report). > > > > On Thu, 23 May 2019 at 19:12, John Ralls wrote: > > > >> Back in the run-up to releasing GnuCash 3.0 when we adopted the > two-digit > >> release numbering we also said that we wanted to accelerate the major > >> release tempo to 2-3 years instead of the 4 years that had gone between > the > >> previous several major releases. > >> > >> Well, it's two years later. We've added almost 1500 commits, but they've > >> all been to the maint branch. There are a few low-effort changes on the > >> table that would fit better into a new stable series, including more > report > >> system updates from Chris Lam and the report menu rearrangement Geert > >> surfaced last week. > >> > >> The first alternative is to finish those up, merge them onto master, and > >> release 4.0 in December as we optimistically planned 2 years ago. Along > >> with that change we'd bump the C++ standard requirement to 14 so that we > >> can use initializer lists correctly. That will require GCC 5.0 or Clang > >> 3.4, which would raise the baseline distros to Ubuntu 16.04, Debian 9, > Mint > >> 18, and Fedora 25. RHEL/Centos users would need to install devtoolset-7 > or > >> devtoolset-8. OpenSuSE users would need to install one of the GCC > upgrade > >> packages. MacOS minimum would bump to 10.10 (Yosemite). MSYS2's > toolchain > >> is consistently bleeding-edge so Windows builds wouldn't be affected. > >> > >> The second alternative is to revert to the 4-year major release tempo, > >> continuing the current 3.x stable series until the end of 2021 and > hoping > >> that we've made sufficient progress on the major goals by then. > >> > >> The third alternative is to not have a fixed major release schedule at > >> all and instead to wait until the goals set out in > >> https://wiki.gnucash.org/wiki/Release_Schedule#Goals_for_4.0 are > >> completed. > >> > >> Geert and I, having discussed this on IRC, are inclined toward the first > >> alternative because it allows us to update the minimum versions of > several > >> dependencies. > >> > >> Regards, > >> John Ralls > >> > >> ___ > >> gnucash-devel mailing list > >> gnucash-devel@gnucash.org > >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel > >> > > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Release Schedule
Oh and also: I'll wish to transition *all* html-acct-table based reports to force them to do subtotals properly. There are currently 9 different combinations for subtotals while displaying accounts, depending on the Display settings "parent account balances" and "parent account subtotals"; the 'canonically-tabbed' option should be deprecated; and either parent account include children-account subtotals, or parent subtotals displayed after their children group. i.e. 9 combinations reduced to 2 options. I'll hope this can be achieved for 4.0. On Fri, 24 May 2019 at 03:07, Christopher Lam wrote: > Hi John > My plans for 4.0 will be > - remove *all* deprecated exported functions and deprecated code paths > - enable book-accounting-period preference > > I'd urge anyone with custom reports will observe the console or tracefile, > and watch for any scheme deprecation warnings while running latest versions > of GnuCash -- old functions are due a major cleanup. If there are, please > let us know via devel or bugzilla (and attach custom report). > > On Thu, 23 May 2019 at 19:12, John Ralls wrote: > >> Back in the run-up to releasing GnuCash 3.0 when we adopted the two-digit >> release numbering we also said that we wanted to accelerate the major >> release tempo to 2-3 years instead of the 4 years that had gone between the >> previous several major releases. >> >> Well, it's two years later. We've added almost 1500 commits, but they've >> all been to the maint branch. There are a few low-effort changes on the >> table that would fit better into a new stable series, including more report >> system updates from Chris Lam and the report menu rearrangement Geert >> surfaced last week. >> >> The first alternative is to finish those up, merge them onto master, and >> release 4.0 in December as we optimistically planned 2 years ago. Along >> with that change we'd bump the C++ standard requirement to 14 so that we >> can use initializer lists correctly. That will require GCC 5.0 or Clang >> 3.4, which would raise the baseline distros to Ubuntu 16.04, Debian 9, Mint >> 18, and Fedora 25. RHEL/Centos users would need to install devtoolset-7 or >> devtoolset-8. OpenSuSE users would need to install one of the GCC upgrade >> packages. MacOS minimum would bump to 10.10 (Yosemite). MSYS2's toolchain >> is consistently bleeding-edge so Windows builds wouldn't be affected. >> >> The second alternative is to revert to the 4-year major release tempo, >> continuing the current 3.x stable series until the end of 2021 and hoping >> that we've made sufficient progress on the major goals by then. >> >> The third alternative is to not have a fixed major release schedule at >> all and instead to wait until the goals set out in >> https://wiki.gnucash.org/wiki/Release_Schedule#Goals_for_4.0 are >> completed. >> >> Geert and I, having discussed this on IRC, are inclined toward the first >> alternative because it allows us to update the minimum versions of several >> dependencies. >> >> Regards, >> John Ralls >> >> ___ >> gnucash-devel mailing list >> gnucash-devel@gnucash.org >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel >> > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] Release Schedule
Hi John My plans for 4.0 will be - remove *all* deprecated exported functions and deprecated code paths - enable book-accounting-period preference I'd urge anyone with custom reports will observe the console or tracefile, and watch for any scheme deprecation warnings while running latest versions of GnuCash -- old functions are due a major cleanup. If there are, please let us know via devel or bugzilla (and attach custom report). On Thu, 23 May 2019 at 19:12, John Ralls wrote: > Back in the run-up to releasing GnuCash 3.0 when we adopted the two-digit > release numbering we also said that we wanted to accelerate the major > release tempo to 2-3 years instead of the 4 years that had gone between the > previous several major releases. > > Well, it's two years later. We've added almost 1500 commits, but they've > all been to the maint branch. There are a few low-effort changes on the > table that would fit better into a new stable series, including more report > system updates from Chris Lam and the report menu rearrangement Geert > surfaced last week. > > The first alternative is to finish those up, merge them onto master, and > release 4.0 in December as we optimistically planned 2 years ago. Along > with that change we'd bump the C++ standard requirement to 14 so that we > can use initializer lists correctly. That will require GCC 5.0 or Clang > 3.4, which would raise the baseline distros to Ubuntu 16.04, Debian 9, Mint > 18, and Fedora 25. RHEL/Centos users would need to install devtoolset-7 or > devtoolset-8. OpenSuSE users would need to install one of the GCC upgrade > packages. MacOS minimum would bump to 10.10 (Yosemite). MSYS2's toolchain > is consistently bleeding-edge so Windows builds wouldn't be affected. > > The second alternative is to revert to the 4-year major release tempo, > continuing the current 3.x stable series until the end of 2021 and hoping > that we've made sufficient progress on the major goals by then. > > The third alternative is to not have a fixed major release schedule at all > and instead to wait until the goals set out in > https://wiki.gnucash.org/wiki/Release_Schedule#Goals_for_4.0 are > completed. > > Geert and I, having discussed this on IRC, are inclined toward the first > alternative because it allows us to update the minimum versions of several > dependencies. > > Regards, > John Ralls > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
