Re: Mac Help works. Since when?

> 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

Re: Access to code.gnucash.org

> 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

Re: On development/release processes and version numbers

> 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

Re: Access to code.gnucash.org

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

Mac Help works. Since when?

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

Access to code.gnucash.org

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

Re: On development/release processes and version numbers

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

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.

Re: Building on MacOS - jhbuild difficulty

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

Comments on unstable release 2.7.3

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

Re: On development/release processes and version numbers

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.

Re: On development/release processes and version numbers

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

Collation of release numbers

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

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

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

On development/release processes and version numbers

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

Re: Beyond 2.8 - version numbering

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 >