[GNC] Upgrade Path from version 2.6.16 on MacOS High Sierra (10.13.6) and beyond

[David T.]

And I will add my comments as well...

> On Jan 28, 2019, at 5:17 PM, Adrien Monteleone <adrien.monteleone at lusfiber.net> wrote:
> 
> Michael,
> 
> I’ll cover these in-line:
> 
>> On Jan 28, 2019, at 4:56 AM, Michael Hendry <hendry.michael at gmail.com> wrote:
>> 
>> I have been contentedly using Gnucash since 2010, initially on Ubuntu but more recently on iMac, and although I have no problems with the version I’m using it’s probably time I upgraded.
>> 
>> I have a few questions:
>> 
>> 1. Will 2.6.16 still run on the Mac when the withdrawal of support for 32-bit software takes place (it was to have taken place with the move from High Sierra to Mojave, but has been deferred until the next OS release)?
> 
> A developer could chime in but my recollection from when this arose last year or so is, “no.” If it were critical to run a 32-bit version, you’ll need a VM running an older version of MacOS. (note that is against the Apple TOS)
> 
> I was involved in a thread on this topic when GnuCash announced they would no longer be releasing a 32-bit app as I was running Snow Leopard (10.6) at the time on a Macbook that couldn’t be upgraded past Lion. (and since that was buggier than Snow Leopard, I left it there)
> 
> I discovered it was possible to install a 64-bit vm of Ubuntu due to the fact that the Core2-Duo chip was 64 bit. (I seem to recall the MacOS limitation is that the logic board was limiting the peripherals to 32-bit and Apple was no longer going to provide 32-bit hardware support, but the linux kernel does.)
> 
> So if you have a hardware limitation, double check your chip. You might be able to run a 64-bit linux on it and use that for GnuCash 3.x. But if you are already on High Sierra, that shouldn’t be an issue.
> 
>> 
>> 2. Can I go straight from 2.6.16 to 3.4 (the current stable release), or do I have to upgrade in stages?
> 
> Not certain, but you might consider upgrading to 2.6.21 first - see next answer.
> 
>> 
>> 3. Are the data files with the newer releases backward-compatible with earlier ones? (i.e. Can I drop back to an earlier version after opening and/or editing my files in the current one?).
> 
> Early 3.x is backwards compatible with 2.6.19-2.6.21 (those last two were snap fixes released shortly after 2.6.19 to fix some showstopper bugs)
> 
> I’m not sure if you lose this backwards compatibility later on in 3.x. I played with both on the same data file through 3.2, but there were some issues. (some data not visible, or displayed properly, but thankfully, not lost)
> 
> ALWAYS switch versions with a COPY of your file. Once you’ve settled on which version you are going to run, then you can work with your main file.

I run 2.6.21 and 3.4 side by side on my machine on the same data file without trouble. The visual experiences can’t be optimized for both since they use different UI engines but the same configuration files it seems. 

There are also numerous incompatibilities with the standard reports between the versions, which make it moderately annoying to run them across versions. Specifically, the Transaction report total settings are completely different and incompatible, making a saved report based on this unusable in one or the other versions. While it would be preferable for these reports to preserve backwards compatibility, I am willing to accept the loss for the joy of having someone finally working on reports...

> 
> 
>> 
>> 4. Is there a tidy way of running two versions on the same computer and keeping their respective data files separate?
> 
> You can install two versions in /Applications but since two files can’t have the same name in the same folder, you’ll need to name them differently. An obvious choice would be to append the version number (or at least the main version number) to the app name.
> 
> You can also install a mac app to anywhere in your home folder. (~/Applications makes it only installed for you) But I’d still recommend appending a version number so you know at a glance, which you are running.
> 
> You’ll need two copies of your data file, and again here, I’d add some sort of renaming convention for version control.

It’s not clear whether “data files” is meant to refer to *your* data files, or *the application’s.* Adrien is right that you can easily load multiple versions of the application simply by naming one “Gnucash 2.6.19.app” and the other “Gnucash 3.4.app”  That is what I have done; I’ve also put both on my dock and use them regularly.

Both of them, however, will default to opening the same data file, again since the same configuration files are used. You could work around this by installing the different versions under different users on MacOS.


> 
> But I can’t see you’d need to maintain this setup for very long.
> 
>> 
>> 5. Is it better to use the compiled version available as a download, or to compile in situ? (I have both MacPorts and Homebrew set up on my computer).
> 
> I’ve compiled GnuCash for Linux many times with little issue. (the app ran fine, it was the actual compile that hit a few snags some times.) I’ve never compiled it for Mac.
> 
> If you’re building the release version, there shouldn’t be any difference. The main reason for compiling would be to test unreleased patches. (or in the case of Linux, to install a version ahead of what is in your distro’s repository)

I stopped compiling GnuCash many years ago. The headaches were just too great. Unless you are actively tracking down bugs or trying to help with development, there is no reason to burden yourself with compiling.

> 
>> 
>> 
>> I see from recent posts that there appear to be difficulties with the uploading of bank statements and of stock market prices,  but I use neither of these features.
>> 
>> My accounts are stored in .gnucash files, not in a database.
> 
> Most of those issues are specific to the bank in question's file format and to the recent switch to AlphaAdvantage for stock quotes where some people download dozens or hundreds of quotes some many times per day.  I don’t use the banking features, but I download commodity prices and a handful of foreign currencies every so often. I’ve never had any serious issues.
> 
> Even if you use the SQlite3 backend, as I do, you’ll still have only one file ending in .gnucash. (and you get the ability to run queries on the data)
> 
> Regards,
> Adrien
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.