On 08/02/2022 12:33, Colin Ingarfield wrote:
Hello,
About a year ago I evaluated beancount to organize my finances. As
recommended at the time I used v2. Made some good progress but my
project fell to the wayside.
Now I'm giving it another shot, and wondering if I should use v2 or v3?
Getting all my financial info together is a fair bit of work, and I'd
rather not change it all if v3 becomes "official" later this year.
FWIW I'm a software developer, so if v3 requires use of git, C++
compilers, etc., that's not an issue. But if it's unstable then I'd
rather move ahead with v2.
Unless you are planning to hack on Beancount or related tools, there is
little to no reason to switch to Beancount v3. Beancount v3 is currently
interchangeable with v2 but this is not a constraint to which we will
necessarily adhere during the development of Beancount v3.
The only major change is in the importers frameworks, which has moved to
the beangulp project and evolved substantially. While the old APIs are
still there (under a different import path) the recommended way to
interact with the importers changes significantly and I plan more
changes before cutting a release. In principle beangulp could be used on
top of Beancount v2, but... please see a message of mine to the mailing
list a while ago for an explanation.
I suggest new users to stay with v2 for now. Read on for more details.
Beancount v3 is mostly plans for a partial port of the Beancount
codebase to C++ to improve performance on large ledgers and clean up
some internal structure. As of now, only the parser has been ported to
C++, switching from Flex to Re/Flex as scanner generator, resulting in a
somehow stricter and more correct parser. However, this code is not used
in a standard install of the v3 branch, which still uses the v2 parser,
thus is of very little consequence for users.
The break of API backward compatibility inherent in the port is also an
excuse to introduce backward incompatibilities at the application level.
With the intent of reducing the scope of the Beancount codebase and
increase the pace of development some parts of Beancount (that most
likely no one will miss) have been removed and some (bean-price,
bean-query, and the importers framework, now respectively beanprice,
beanquery, and beangulp) have been split off from the main repository.
Other than that, only very minor API cleanup happened in the v3 branch.
I use v2 and v3 interchangeably. I know that Martin uses v3.
While the API is almost identical, most projects that build on Beancount
as a library expect and v2 only. One consequence is that Python
packaging may have to be coerced into accepting Beancount v3 as a
dependency, and if any of the functionality moved to the side
repositories is used, imports need to be modified accordingly (other
than that, for the moment, I try to maintain API compatibility with v2).
Beancount v3 is the only branch where development continues. Only
serious bug fixes are (sporadically, for lack of time) applied to v2. I
don't expect anything major to happen in the v3 development any time soon.
Cheers,
Dan
--
You received this message because you are subscribed to the Google Groups
"Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beancount/fe071645-b7b8-2aed-0b66-d18ae349a76f%40grinta.net.
