Re: Mac Help works. Since when?

[John Ralls]

> On Jan 25, 2018, at 8:14 PM, D via gnucash-devel  
> wrote:
> 
> Hello,
> 
> Another wiki thing, probably for John. The FAQ includes a Mac question about 
> how to get help to work, but I know that it currently (2.6.19) works out of 
> the box, and has for a few versions now. I hesitate to delete the question 
> outright, though, because people are known to use older versions all the 
> time. So, the question is, for which release was the help system fixed on the 
> Mac? I will change the FAQ to identify the version, once I know this.

2.3.13, though you should probably say 2.4.0 in the wiki.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Access to code.gnucash.org

[John Ralls]

> On Jan 25, 2018, at 8:09 PM, D via gnucash-devel  
> wrote:
> 
> Hello,
> 
> I am editing the various wiki pages that address using git (mostly, "Git" and 
> "Git for Newbies"), and I noted that on the Git page, it talks about 
> connecting to code.gnucash.org. The newbie page, however talks solely about 
> connecting through github. My question is this: aside from the core 
> developers, is anyone supposed to work directly with code.gnucash.org? Should 
> it even be mentioned on the Git instruction pages, or should that be put into 
> some other page? My sense is that non-committing (noncommittal?) contributors 
> are only going to use github. Am I wrong in this assumption?

David,

Yes, only core developers have the ssh keys neededto access code.gnucash.org 
. Since not all of the core developers are active 
enough to be really proficient we do need a place to put the procedure for 
them, but if there’s a way to hide it from everyone else I guess that’d be OK.

While git is older than GitHub, it isn’t by much and both predate GnuCash’s 
adoption of git and the Git wiki page by many years. But when the Git page was 
first written the primary audience was very much the core developers most of 
whom were using git for the first time after many years of using subversion. 
That’s what’s changed.

If one has an ssh key for code it doesn’t matter much which one pulls from. The 
important thing is to never push to GitHub or use its automatic merge tools 
because code can sync *to* GitHub but can’t sync from it.

Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: On development/release processes and version numbers

[John Ralls]

> On Jan 25, 2018, at 5:42 PM, Glen Ditchfield  wrote:
> 
> Regarding EOL management, I think you will soon have three supported
> "product lines": the upcoming 3.0, a 2.6.x series (2.6.19, 2.6.20,
> ...), and a 2.4.x series.   (The level of support might be something
> low like "security fixes only".)  3.1 will likely come out before 2.6.x
> reaches end-of-life.
> 
> If that is correct, you'll have to be able develop bug fixes that don't
> apply to all of the supported series.  I don't think that will be easy
> if you have just one bugfix branch.
> 
> I looked around and couldn't find any helpful Git advice for projects
> that have more than one supported version.  Every detailed work flow
> seemed to assume that there just one blob of current production code,
> and one development branch.  
> 
> Perhaps this would work:
> * Normal development (refactorings, enhancements, etc) goes on master.
> * Every supported series has a branch: for now, create releases-2.6.x
>   and releases-2.4.x.  Bug fixes accumulate on these branches.
> * Use feature branches for development: every enhancement and every
>   bug fix gets its own branch.  Enhancements branch off from master. 
>   Bug fixes for old versions branch off from a releases-* branch.
> * When the time comes to prepare for the GnuCash 3 release, create
>   branch releases-3.0.x from master.  Make any necessary adjustments
>   to the releases-3.0.x branch, and tag the result as v3.0.0.  Any
>   work done on master after the branch will be part of v3.1.0.

Nope. We do a final release of the previous stable branch concurrent with the 
first release of the new stable branch, so 2.4 stopped with 2.4.14, released 
the same day as 2.6.0. 2.6 support will end with 2.6.20 that will be released 
with 3.0, and 3.x will be the only supported branch until we start a new 
unstable release cycle in 4 years or so (unless we decide to change the “major” 
release tempo).

There’s a reason that you couldn’t find much about it: It’s rare because it’s 
hard. Even projects that have lots of developers like the Linux Kernel don’t do 
it.

Resource constraints aside, the problem with having more than two branches or 
with letting parallel branches live too long is code divergence and up-merges. 
Merging maint into unstable is already a major pain-point and I’ll be really 
happy to get 3.0 out so that we don’t have to merge from what will then be the 
2.6 branch any more.

If the pace of master development picks up we may have to accelerate the 
“major” release tempo to avoid up-merge problems from converting the main 
engine classes to C++. We’ll see.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Access to code.gnucash.org

[Frank H. Ellenberger]

Hi David,

Am 26.01.2018 um 05:09 schrieb D via gnucash-devel:
> Hello,
> 
> I am editing the various wiki pages that address using git (mostly, "Git" and 
> "Git for Newbies"), and I noted that on the Git page, it talks about 
> connecting to code.gnucash.org. The newbie page, however talks solely about 
> connecting through github. My question is this: aside from the core 
> developers, is anyone supposed to work directly with code.gnucash.org? Should 
> it even be mentioned on the Git instruction pages, or should that be put into 
> some other page? My sense is that non-committing (noncommittal?) contributors 
> are only going to use github. Am I wrong in this assumption?
> 
> David

it is really simple. The usage of git is older than that of github. So
the page might have obsolete details.

Everybody should pull from github.

Core devs must push to code.gnucash.org,
others to their own fork which usually will be on github.

BTW, I saw in your recent edits "lists.gnucash.org/docs/...".
While currently it is physically the same, I would use
"code.gnucash.org" - the build server, instead of the mailing lists server.

Cheers
Frank

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Mac Help works. Since when?

[D via gnucash-devel]

Hello,

Another wiki thing, probably for John. The FAQ includes a Mac question about 
how to get help to work, but I know that it currently (2.6.19) works out of the 
box, and has for a few versions now. I hesitate to delete the question 
outright, though, because people are known to use older versions all the time. 
So, the question is, for which release was the help system fixed on the Mac? I 
will change the FAQ to identify the version, once I know this.

TIA,
David
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Access to code.gnucash.org

[D via gnucash-devel]

Hello,

I am editing the various wiki pages that address using git (mostly, "Git" and 
"Git for Newbies"), and I noted that on the Git page, it talks about connecting 
to code.gnucash.org. The newbie page, however talks solely about connecting 
through github. My question is this: aside from the core developers, is anyone 
supposed to work directly with code.gnucash.org? Should it even be mentioned on 
the Git instruction pages, or should that be put into some other page? My sense 
is that non-committing (noncommittal?) contributors are only going to use 
github. Am I wrong in this assumption?

David
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: On development/release processes and version numbers

[Matt Graham]

As a Noob following this with interest:
1. If a platform makes a decision that breaks a previous stable version, it 
could be a case if create a quick fix branch off that version tag, and release 
an extra ".1". So 2.6.1 would become 2.6.1.1. Note that I am assuming that this 
is rare and that most people are keeping up to date with stable releases (so 
most bugs are off that).

2. Ultimately, it sounds like step 1 (regardless of which version control 
labelling is used) is to try to automate as much of the "release process" as 
possible. This frees up time from an experienced coder.
Should we have a separate part of the source code for release scripts (that the 
release manager can just run)? Is this something that people like me can help 
with? (Not that I know enough yet to be much help...)

Thanks and regards,
Matt


 Original message 
From: Glen Ditchfield 
Date: 26/1/18 12:43 (GMT+10:00)
To: gnucash-devel@gnucash.org
Subject: Re: On development/release processes and version numbers

Regarding EOL management, I think you will soon have three supported
"product lines": the upcoming 3.0, a 2.6.x series (2.6.19, 2.6.20,
...), and a 2.4.x series.   (The level of support might be something
low like "security fixes only".)  3.1 will likely come out before 2.6.x
reaches end-of-life.

If that is correct, you'll have to be able develop bug fixes that don't
apply to all of the supported series.  I don't think that will be easy
if you have just one bugfix branch.

I looked around and couldn't find any helpful Git advice for projects
that have more than one supported version.  Every detailed work flow
seemed to assume that there just one blob of current production code,
and one development branch.

Perhaps this would work:
 * Normal development (refactorings, enhancements, etc) goes on master.
 * Every supported series has a branch: for now, create releases-2.6.x
   and releases-2.4.x.  Bug fixes accumulate on these branches.
 * Use feature branches for development: every enhancement and every
   bug fix gets its own branch.  Enhancements branch off from master.
   Bug fixes for old versions branch off from a releases-* branch.
 * When the time comes to prepare for the GnuCash 3 release, create
   branch releases-3.0.x from master.  Make any necessary adjustments
   to the releases-3.0.x branch, and tag the result as v3.0.0.  Any
   work done on master after the branch will be part of v3.1.0.

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.gnucash.org%2Fmailman%2Flistinfo%2Fgnucash-devel=02%7C01%7C%7C398a5e971c26478e833508d5645e22fc%7C84df9e7fe9f640afb435%7C1%7C0%7C636525277829194997=jxw9jYSj39B%2B%2ByIsE7ElE8fwm5d6pNFie3JU%2FMpEph4%3D=0
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: On development/release processes and version numbers

[Glen Ditchfield]

Regarding EOL management, I think you will soon have three supported
"product lines": the upcoming 3.0, a 2.6.x series (2.6.19, 2.6.20,
...), and a 2.4.x series.   (The level of support might be something
low like "security fixes only".)  3.1 will likely come out before 2.6.x
reaches end-of-life.

If that is correct, you'll have to be able develop bug fixes that don't
apply to all of the supported series.  I don't think that will be easy
if you have just one bugfix branch.

I looked around and couldn't find any helpful Git advice for projects
that have more than one supported version.  Every detailed work flow
seemed to assume that there just one blob of current production code,
and one development branch.  

Perhaps this would work:
 * Normal development (refactorings, enhancements, etc) goes on master.
 * Every supported series has a branch: for now, create releases-2.6.x
   and releases-2.4.x.  Bug fixes accumulate on these branches.
 * Use feature branches for development: every enhancement and every
   bug fix gets its own branch.  Enhancements branch off from master. 
   Bug fixes for old versions branch off from a releases-* branch.
 * When the time comes to prepare for the GnuCash 3 release, create
   branch releases-3.0.x from master.  Make any necessary adjustments
   to the releases-3.0.x branch, and tag the result as v3.0.0.  Any
   work done on master after the branch will be part of v3.1.0.

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on MacOS - jhbuild difficulty

[John Ralls]

I resolved it by selecting 4, then from the shell:

git reset --hard
git checkout master
autoreconf -fis && ./configure --prefix $PREFIX
exit
 1

Regards,
John Ralls


> On Jan 24, 2018, at 6:10 PM, R. Victor Klassen  wrote:
> 
> Easy enough:
> 
> make[3]: Nothing to be done for `all-am'.
> Making all in openssl
>   CC   libxmlsec1_openssl_la-ciphers.lo
>   CC   libxmlsec1_openssl_la-digests.lo
>   CC   libxmlsec1_openssl_la-evp.lo
>   CC   libxmlsec1_openssl_la-hmac.lo
>   CC   libxmlsec1_openssl_la-kw_aes.lo
> ciphers.c:39:25: error: field has incomplete type 'EVP_CIPHER_CTX' (aka 
> 'struct evp_cipher_ctx_st')
> EVP_CIPHER_CTX  cipherCtx;hmac.c:78:25: error: field has incomplete 
> type 'HMAC_CTX' (aka 'struct hmac_ctx_st')
> HMAC_CTXhmacCtx;
> ^
> /Users/gnucashdev/gnucash-stable/include/openssl/ossl_typ.h:102:16: note: 
> forward declaration of 'struct hmac_ctx_st'
> typedef struct hmac_ctx_st HMAC_CTX;
>^
> digests.c:31:25: error: field has incomplete type 'EVP_MD_CTX' (aka 'struct 
> evp_md_ctx_st')
> EVP_MD_CTX  digestCtx;
> ^
> /Users/gnucashdev/gnucash-stable/include/openssl/ossl_typ.h:92:16: note: 
> forward declaration of 'struct evp_md_ctx_st'
> typedef struct evp_md_ctx_st EVP_MD_CTX;
>^
> 
> ^
> /Users/gnucashdev/gnucash-stable/include/openssl/ossl_typ.h:90:16: note: 
> forward declaration of 'struct evp_cipher_ctx_st'
> typedef struct evp_cipher_ctx_st EVP_CIPHER_CTX;
>^
> evp.c:185:11: warning: implicit declaration of function 'CRYPTO_add' is 
> invalid in C99 [-Wimplicit-function-declaration]
> ret = CRYPTO_add(>references,1,CRYPTO_LOCK_EVP_PKEY);
>   ^
> digests.c:216:5: warning: implicit declaration of function 
> 'EVP_MD_CTX_cleanup' is invalid in C99 [-Wimplicit-function-declaration]
> EVP_MD_CTX_cleanup(&(ctx->digestCtx));
> ^
> hmac.c:236:5: warning: implicit declaration of function 'HMAC_CTX_init' is 
> invalid in C99 [-Wimplicit-function-declaration]
> HMAC_CTX_init(&(ctx->hmacCtx));
> ^
> hmac.c:252:5: warning: implicit declaration of function 'HMAC_CTX_cleanup' is 
> invalid in C99 [-Wimplicit-function-declaration]
> HMAC_CTX_cleanup(&(ctx->hmacCtx));
> ^
> hmac.c:357:5: warning: 'HMAC_Init' is deprecated [-Wdeprecated-declarations]
> HMAC_Init(&(ctx->hmacCtx),
> ^
> /Users/gnucashdev/gnucash-stable/include/openssl/hmac.h:28:1: note: 
> 'HMAC_Init' has been explicitly marked deprecated here
> DEPRECATEDIN_1_1_0(__owur int HMAC_Init(HMAC_CTX *ctx, const void *key, int 
> len,
> ^
> /Users/gnucashdev/gnucash-stable/include/openssl/opensslconf.h:130:34: note: 
> expanded from macro 'DEPRECATEDIN_1_1_0'
> # define DEPRECATEDIN_1_1_0(f)   DECLARE_DEPRECATED(f)
>  ^
> /Users/gnucashdev/gnucash-stable/include/openssl/opensslconf.h:105:53: note: 
> expanded from macro 'DECLARE_DEPRECATED'
> # define DECLARE_DEPRECATED(f)f __attribute__ ((deprecated));
> ^
> evp.c:185:27: error: incomplete definition of type 'struct evp_pkey_st'
> ret = CRYPTO_add(>references,1,CRYPTO_LOCK_EVP_PKEY);
>   ^
> /Users/gnucashdev/gnucash-stable/include/openssl/ossl_typ.h:93:16: note: 
> forward declaration of 'struct evp_pkey_st'
> typedef struct evp_pkey_st EVP_PKEY;
>^
> 1 warning and 1 error generated.
> 1 error generated.
> 3 warnings and 1 error generated.
> make[3]: *** [libxmlsec1_openssl_la-digests.lo] Error 1
> make[3]: *** Waiting for unfinished jobs
> make[3]: *** [libxmlsec1_openssl_la-ciphers.lo] Error 1
> evp.c:185:42: error: use of undeclared identifier 'CRYPTO_LOCK_EVP_PKEY'
> ret = CRYPTO_add(>references,1,CRYPTO_LOCK_EVP_PKEY);
>  ^
> evp.c:213:16: error: incomplete definition of type 'struct evp_pkey_st'
> switch(pKey->type) {
>^
> /Users/gnucashdev/gnucash-stable/include/openssl/ossl_typ.h:93:16: note: 
> forward declaration of 'struct evp_pkey_st'
> typedef struct evp_pkey_st EVP_PKEY;
>^
> make[3]: *** [libxmlsec1_openssl_la-hmac.lo] Error 1
> evp.c:505:42: error: incomplete definition of type 'struct evp_pkey_st'
> xmlSecAssert2((pKey == NULL) || (pKey->type == EVP_PKEY_DSA), NULL);
>  ^
> ../../include/xmlsec/errors.h:487:15: note: expanded from macro 
> 'xmlSecAssert2'
> if(!( p ) ) { \
>   ^
> /Users/gnucashdev/gnucash-stable/include/openssl/ossl_typ.h:93:16: note: 
> forward declaration of 'struct evp_pkey_st'
> typedef struct evp_pkey_st EVP_PKEY;
>^
> evp.c:507:33: error: incomplete definition of type 'struct evp_pkey_st'
> return((pKey != NULL) ? pKey->pkey.dsa : (DSA*)NULL);
> ^
> 

Comments on unstable release 2.7.3

[David Carlson]

 quick search did not yield a good place to post comments on release 2.7.3.

I don't think that any of my comments are reporting actual bugs, they are
mainly noting differences from the stable release.

I will put a teaser or two in this message.

As I reported on the user list, this release takes about 8-1/2 minutes on
first load and 7 minutes thereafter on my data file as compared to 4
minutes with release 2.6.18 in Windows.

The meta-data migrated message is nice except it says my metadata  is now
on V with no additional characters to tell me where V is. Where is it?

The links to the Help files in the menu do not seem to be active.

David C
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: On development/release processes and version numbers

[Adrien Monteleone]

For clarification, Ubuntu supports their LTS for 5 years, (both desktop and 
server) but they release one every 2 years. Debian adopted a similar approach, 
but the two are a year out of sync.

As most know, Ubuntu uses a date based version numbering scheme with point 
releases for bug fixes. Debian also uses a timed-release model, but they use 
x.y.z notation instead of yy.mm.z

RHEL offers standard support for 5 years, but they have 3 additional support 
levels topping out at 10 years total, with the option for special add-on 
support long beyond that. (for the right price I’m sure) I didn’t check their 
release cadence against Debian/Ubuntu.

Libreoffice also uses a time-based release x.y.z scheme where ’x’ is the next 
major release (in their case, every 2.5 years), ‘y’ includes new features and 
is released every 6 months (supported for 9) and ‘z’ is a monthly bug-fix 
release. They support 2 released x.y versions at a time (for about 9 months 
each) with a third being always bleeding edge as the next release. They do note 
that this process is resource intensive despite (or because of) their large 
team. I would think this has more to do with the tight schedule though rather 
than the general scheme itself.

If the goal is to look ‘fresh’ for users, then I’d think a time-based numbering 
scheme is the way to go. (either by dates, or x.y.z) But if semantic versioning 
is more important, then you’re destined to appear ‘stale’ since development of 
major improvements is slow to occur due to a small team and limited resources. 
(not that I think anyone is complaining, everyone working on this project is 
much appreciated)

Based on the GnuCash release cadence I would think a 2 year LTS policy would be 
sufficient to maintain with bug-fixes only, while all new features (even minor 
ones) and major changes go into the ‘fresh’ version. Two versions seems like 
the least amount of work and is pretty fair.

There are two other topics that might assist with the ‘stale vs. fresh’ 
impression: reports and modules. Judging by the mailing list topics, it seems 
reporting is the area users care most about having as a new ‘feature’ than 
actual application functionality. Certainly, reports can be added or improved 
for the LTS users since they are able to be installed separately and don’t 
really constitute new ‘features’ in the main app. As long as the plugin-module 
model is supported, that route can offer ‘new features’ as well until they are 
integrated into main. With those two in mind, the LTS policy could even be 5 
years since it would be possible to add-on needed improvements while the core 
dev work is on toolkits, MVC, language rebasing and moving to full database 
usage. (those report writers and plugin maintainers would have to keep up with 
the ‘fresh’ version of course, maybe even merging into it for the next major 
release, but their original code will last as long as the LTS policy)

Just some thoughts,
Adrien

> On Jan 25, 2018, at 1:41 PM, cicko  wrote:
> 
> Looks like a start of an interesting discussion.
> I'll chip in just a few drops at this time and won't repeat myself in terms
> of personal preferences for the version numbers because there are other
> concerns to take into consideration there, as well.
> 
> The release management need not necessarily be tied to the development and
> code branching strategy. Here is an interesting model that I've tried to
> emulate in practice but never got as far as having the full spectre of
> branches in a repo (mostly because I never had git in professional projects
> and Open Source ones are fairly small for the full model :'( ). It is
> interesting, nonetheless, to read into it and utilize the ease of switching
> and merging branches git provides.
> http://nvie.com/posts/a-successful-git-branching-model/
> In brief, you could still have two main branches: unstable and stable. There
> are numerous other branches in practice. The feature branches merge to
> unstable, while hotfixes merge to stable branch. In this model, master is
> the stable branch, the mirror image of the GnuCash branch stability, but the
> practical difference is just in branch names. The code flow is likely still
> the same. What I find quite practical with git is that there can be lots of
> active branches that span from the main two - unstable and stable - and are
> used for new feature development or bug fixes.
> An opposite, perpendicular approach would be a branch per version number.
> This model is more oriented towards end-users and, in my opinion, makes more
> sense for large providers with a large and profitable user base. This seems
> very demanding on the development team as well as the release management
> process.
> 
> As far as product management goes, with release version numbers, there will
> be lots of factors, I guess. As you mentioned, supporting certain versions
> in order to follow other vendors' policies might be one. But, politics
> aside, 

Re: On development/release processes and version numbers

[cicko]

Looks like a start of an interesting discussion.
I'll chip in just a few drops at this time and won't repeat myself in terms
of personal preferences for the version numbers because there are other
concerns to take into consideration there, as well.

The release management need not necessarily be tied to the development and
code branching strategy. Here is an interesting model that I've tried to
emulate in practice but never got as far as having the full spectre of
branches in a repo (mostly because I never had git in professional projects
and Open Source ones are fairly small for the full model :'( ). It is
interesting, nonetheless, to read into it and utilize the ease of switching
and merging branches git provides.
http://nvie.com/posts/a-successful-git-branching-model/
In brief, you could still have two main branches: unstable and stable. There
are numerous other branches in practice. The feature branches merge to
unstable, while hotfixes merge to stable branch. In this model, master is
the stable branch, the mirror image of the GnuCash branch stability, but the
practical difference is just in branch names. The code flow is likely still
the same. What I find quite practical with git is that there can be lots of
active branches that span from the main two - unstable and stable - and are
used for new feature development or bug fixes.
An opposite, perpendicular approach would be a branch per version number.
This model is more oriented towards end-users and, in my opinion, makes more
sense for large providers with a large and profitable user base. This seems
very demanding on the development team as well as the release management
process.

As far as product management goes, with release version numbers, there will
be lots of factors, I guess. As you mentioned, supporting certain versions
in order to follow other vendors' policies might be one. But, politics
aside, what I find practical for the release schedule GnuCash follows at the
moment, is to have the version numbers still provide the information with
semantic versioning but not necessarily providing much overhead in terms of
maintaining the code branches. What I mean is, the numbers increase like on
a measuring device. The third number (bugfix) releases happen only until the
next minor version comes out. Then this becomes the latest version and
bugfixes are release only for this version. I.e.
- you do some work -> release 1.0.0
- features are being developed in feature branches
- bug found. Release goes out, not waiting for the features to be complete.
-> 1.0.1
- one feature complete -> 1.1.0
- another bug fixed -> 1.1.1
- big feature complete -> 2.0.0
- another bug fixed -> 2.0.1
and so on.
There are several aspects here. Once a minor release is out, the maintenance
is only done on that latest release, not on any of the previous ones. Users
are expected to upgrade because there are no breaking changes involved.
Releasing a major version might be a different story but in the simple case
everything goes just like with minor version. Whether and for how long the
previous versions are supported in practice depends on several factors:
- the amount of development overhead and effort in maintaining the previous
releases,
- the amount of time/effort that goes into testing the future releases
(meaning how stable they are in their x.0.0 version).
Maintaining several active versions requires decent amount of testing of
*all* of them and I am not a big fan of that scenario. That grows the
efforts exponentially while providing a questionable result. You'll have to
weigh on whether the results are worth the effort.

The versions also do not need to be scheduled, although that's a nice touch
when I look from the end-user's perspective. You could simply release
whenever there are some updates. This gets both the features and bug fixes
into production faster. Which is not necessarily always a good thing. 

These are just some observations that may or may not apply to GnuCash. But I
always enjoy the discussion about these matters. :)



--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Collation of release numbers

[Jim DeLaHunt]

Gnucash developers:

I am reading the thread about release numbering schemes with interest. I 
don't have strong opinions on the big issues you are discussing. I would 
like to touch on a small issue which hasn't come up yet:


*Collation of release numbers*

When you define the new release numbering scheme, be sure to be clear 
about how to determine if one release number is newer or older than 
another release number.  In particular, there's a temptation to do 
lexical comparisons of release numbers, but numeric comparisons by 
number part is probably better.


It's no problem to determine that version 3.1.0 is newer than version 
3.0.9, and that 3.1.2 is newer than 3.1.0.


But, is 3.0.10 newer than 3.0.9?  If comparing lexically, then no. If 
treating the version number as a sequence of three parts, and comparing 
each part numerically, then yes.


There was talk about using version number parts in the 80's or 90's for 
development releases leading up to a new production release.  For 
instance, 3.1.2 and 3.1.9 and 3.1.10 would be production releases in the 
3.1 line; 3.1.80 and 3.1.81 would be development releases leading up to 
3.2.0 and the 3.2 line.  With lexical ordering, 3.1.80 sorts before 
3.1.9, which is wrong. (3.1.10 sorts lexically before 3.1.9, which is 
also wrong.)  If using numbers in the 80's and 90's for development 
releases, it's especially important to be clear that version numbers are 
compared numerically by number part.


Also, be clear if anything but an unsigned integer value is permitted in 
a version.  Will there ever be a version number format like "3.0.1b2"?


Also, be clear if leading zeros are permitted in a version number. Is 
"3.1.09" permitted?   Is it another way to express "3.1.9", or does it 
mean something different?


No matter what version numbering scheme you adopt next, and no matter 
how the semantics of the version number tie to the development process, 
I think it will be helpful to be explicit and clear about collation of 
version numbers.


Thank you,
  —Jim DeLaHunt, Vancouver, Canada

--
--Jim DeLaHunt, j...@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/)
  multilingual websites consultant

  355-1027 Davie St, Vancouver BC V6E 4L2, Canada
 Canada mobile +1-604-376-8953

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: how exactly to do unit testing in scheme...

[Phil Longstaff]

Usually, unit testing controller code is done by writing mocks for the code
that is called. In this case, this would be the options.scm controller and
the renderer. The mock code would test that the expected arguments are
passed, and would return a canned response. This both checks the logic of
the controller but also allows error and other paths to be tested.

On Wed, Jan 24, 2018 at 11:03 AM, Christopher Lam  wrote:

> Dear Devel
>
> To rgmerk: Welcome back, and it was a nice to meet irl!
>
> While simplifying transaction.scm and thinking of unit testing, I now have
> a conundrum worthy of an expert view.
>
> The reports require 2 main functions – the options generator and the
> renderer; the options generator generates a options.scm controller object,
> and the renderer takes options and outputs html.
>
> I understand unit testing to handle testing of ‘leaf’ functions e.g.
> (split->date), rather than the controller code (e.g. renderer takes options
> and outputs html) – but to me this is rather silly because split->date only
> tests xaccTransGetDate and xaccSplitGetParent, whereas the controller tests
> actual functionality.
>
> With regards to unit testing I can see several issues
>
> 1) The refactored report has inlined most single-use functions into lambda
> expressions – I figured that directly stating (xaccTransGetDate
> (xaccSplitGetParent split)) is much more descriptive to a programmer than
> to create a testable leaf function (split->date split). I can see the
> benefits of both – leave as lambda expressions which will can be
> understandable by anyone who is familiar with the API, or break them out
> into 100s of single use functions which can be tested, but introduces a
> whole layer of cognitive load to anyone hacking code – (what does
> split->date actually do? Where is its definition). Also, breaking the
> lambda functions into testable functions means the implementation is frozen
> and the next hacker will have lesser scope to rework/optimise the report.
>
> 2) The refactored report is now flexible enough to accommodate derived
> reports with a different multicolumn data function – eg
> income-gst-statement.scm has been reworked into a transaction.scm
> derivative which passes its own calculated-cells to report on GST sales and
> purchases. This is not yet committed.
>
> 3) I think the most useful testing approach for a complex transaction.scm
> will be to test functions of various combinations of options values, and
> test the resulting html for satisfactory output. There are now dozens of
> bools and multichoices that can be triggered, each effecting html in
> various ways. How best to test?
>
> 4) My view would be the unit test would check that:
> a. the TR actually exists
> b. it can display empty-report
> c. it can understand passing of custom-calculated-cells
> d. each of the options can be toggled, and the resulting html
> displays/hides cells/detail as expected
> e. and sorting options generate sorted rows
>
> Comments welcome, I had no formal training ☹
> ___
> 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

On development/release processes and version numbers

[Geert Janssens]

To start, this will be a long read to introspect on our development and 
release processes, where they are now and where the may go in the future. If 
you want to help shape this future, please read on and share your thoughts.


I have started a thread earlier with a proposal to update our versioning 
scheme for the upcoming major release.

So far the short summary is that most agree we can switch to 3.0 rather than 
2.8. The debate is still open on two related aspects:
- should we continue with a 3-level number or switch to a two-level one
- how should we indicate unstable versions: 
  * via a distinction between even/odd number
  * via .9xx
  * via another extension such as alpha/beta (a/b)...

Before bringing this to a final decision I want to make a detour to our 
development and release process ("our processes" in short from now on) as the 
discussion so far has lead in that direction regularly. In the end I believe 
whatever version number scheme we decide upon should reflect how we develop 
and release gnucash.

Current situation:
- we develop on two primary branches: maint and master.
- on the maint branch we accept bugfixes and small compatible features
- all other development goes on master. This includes major refactorings, 
incompatible changes (though we usually do our best to provide compatibility 
code in maint), big new features, important dependency updates,...
- we do regular "stable" releases from the maint branch (once every 3 months, 
or once every month early in the stable cycle)
- we never release from master. Near the end of a major cycle (which is not 
strictly defined) we branch off a separate branch to stabilize whatever is on 
master at that point and do beta releases from that separate branch (monthly).


However due to our current version number scheme users and distro maintainers 
seem to believe we have 3 levels of development, usually seen as
- bugfixes
- new features (I'll refer to those as enhancements from now on to avoid 
confusion with our current use of the term 'feature branch')
- incompatible changes

I personally care more about stability than about a distinction between pure 
bugfixes and enhancements. Others appear to believe the former can only exist 
thanks to the latter though. Some distros have strict bugfix-only policies in 
stable releases.

This conflict between actual development process and user perception was one 
of the reasons I started this whole version proposal. Originally it didn't 
even occur to me we could question our processes. I immediately proposed to 
switch to a 2 level version number. And even when others pointed out the other 
possibility my knee-jerk reaction was still adjusting our processes to 
accommodate 3 levels would increase the maintenance burden too much.

But does it ? Let's do at least the thought experiment.
What assumptions do we have about our processes that may no longer be relevant 
now ? Below I'll put up an alternative process for others to think about. It's 
not intended to be the perfect solution, but something to start the 
discussion.

1. A 3-level development model would require 3 rather than 2 primary branches 
in git: master (as now), enhancements (for compatible enhancements) and 
bugfixes (for guess what). In the svn days, everybody would cringe even at the 
thought of having yet another branch to maintain. However in git this has 
become relatively painless. There are still merge conflicts but git really 
goes a long way in making multiple branch development pretty manageable. So 
having a 3-level branch strategy would be realistic. bugfix would be the 
oldest branch. Everything committed to bugfix would eventually be merged 
upwards into enhancements. And all enhancements and bugfixes would eventually 
get merged upwards in master. So far so good.

2. But what with releases ? It starts simple: one does a bugfix release at 
fixed intervals from the bugfix branch, and enhancement releases from the 
enhancement branch. Both can have their own cadence. However it quickly gets 
more complicated when a bug needs to be fixed in a new enhancement. Now one 
needs a bugfix branch on the enhancement branch and this would happen again 
with the next feature release. So rather than one bugfix branch we'd need a 
bugfix branch starting at each enhancement branch release. Branch-wise git can 
still manage this perfectly fine.

3. So back to release aspect itself. Having more branches means more releases 
as well. As things stand each release takes a substantial amount of time from 
our release manager. I don't know the exact amount, but I know there's a long 
list of manual steps that have to be repeated for each release. If releases 
are not too frequent, this is acceptable. However if the number of releases 
increases, the time spent on doing them will become more significant and that 
would be time our valued release manager can't spend on actually improving 
gnucash. So that's an important question: can we automate 

Re: Beyond 2.8 - version numbering

[Geert Janssens]

Op woensdag 10 januari 2018 19:37:30 CET schreef Adrien Monteleone:
> Would you switch numbering schemes entirely if you switched to Qt? I suppose
> until GnuCash adopts an MVC approach, incrementing the major version with
> gtk (or Qt) changes has merit, but I would think the ‘cleaner’ approach
> would be to have your own versioning scheme independent of platform,
> toolkits, or even underlying language.

Yes, that's my view on this as well.

> >>> As for whether to drop the third entry is less important to me, but I
> >>> still think it makes sense to have 3.0.0, 3.0.1, etc., for bugfixes and
> >>> leave 3.1/3.2 for more major changes.
> >> 
> >> +1
> > 
> > So this indirectly advocates to keep a distinction between fundamental
> > changes and major changes. What criteria make this distinction in a way
> > that's relevant enough to a maintainer and - even more importantly - an
> > end user to do so ?
> 
> I would think file incompatibility is a clear distinction. But if that’s not
> the case, the developers will have to come up with their own guidelines.
> Rebasing major portions of the code (as you are currently doing) might be
> just such a reason.
> 
> Personally, I’d be confused as a user if an update was only a bug fix and
> the minor number changed. I’d expect to see new features as well in that
> case. That may be simply a matter of habit, though since that usage is so
> pervasive, I’m sure I’m not the only one with such expectations.

The more I read such remarks the more I'm convinced our current version 
mechanism is wrong :-)
We change our minor number changes (I presume you are referring to the middle 
number in semantic versioning), each time we release a version of gnucash that 
can have *incompatible* changes, in addition to new features. Whenever the 
micro version changes (the last number), that can mean bugfixes *and* small 
new (compatible) features. So you're already making wrong conclusions based on 
our version numbers.

People keep referring to the distinction between bugfixes, new features and 
"major changes (typically incompatible)". So they suggest 3 levels. I'll 
repeat our current release process *in practice* only has two levels: major 
releases and bug fix releases. The latter can also include smaller features 
and enhancements. The former can be a mix of all: bugfixes, new features and 
major changes.

> I’m still getting my feet wet learning GnuCash code, and haven’t made any
> commits, so I wasn’t going to chime in at all on this topic, but what you
> describe here was the first thing I thought of when you opened the thread.
> If the development approach is more incremental and less major-all-at-once
> release then why not move to a date based versioning system?
> 
While a valuable suggestion a date based system has a few major drawbacks for 
me:
1. it doesn't convey any semantic information at all. So from a purely date 
based system a user can't tell whether the new version comes with incompatible 
changes or not.
2. it tends to be associated with releases at fixed intervals. While our bug 
fix releases are more or less at fixed intervals we currently don't make that 
same commitment for our major releases. In addition we still have a very slow 
major development cycle (3+ years).
3. As we do make a distinction between bugfix and major releases, a hybrid 
form could be to update a date number for major releases and update an 
incremental number for bugfix releases. Given our slow major cycle we'd jump 
from say 18.x to 21.0 on the first next major release. So if users expect the 
first number to be a year, version 18.y would look quite dated and stale in 
the year 2020, something we hoped to avoid instead with a year based scheme.

> > Semantic versioning proposes an in between number for backwards compatible
> > new features. We don't have that intermediate level. Depending on the
> > complexity and size we decide to add a new feature to the next major
> > version or in the next bugfix release. (Note the new gtk versioning
> > semantics do follow this pattern more closely and they do use the 3
> > numbers in this semantic way from now on as far as I understand).
> 
> So new features appear in bugfix releases without changing the minor number?
> (the ‘y’ in x.y.z)
> 
> It seems to me the problem isn’t so much what scheme to follow but that
> there really isn’t one being followed. If a new feature was introduced in
> 2.6.19 that didn’t exist in 2.6.18 then why didn’t the version change to
> 2.7.0? (or 2.8.0 if you’re using odd minors for testing)
> 
Because we don't make a distinction between a small compatible new feature and 
a bugfix.

And as said earlier, making a distinction between features and bugfixes would 
require a different release model possibly involving more work than we can 
manage.

> If you are introducing new features every ‘z’ release to the point the
> numbers would get silly, then that tells me the case for a date based
> system is quite strong.