[GNC-dev] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

John Ralls jralls at ceridwen.us
Sat Jun 2 20:28:27 EDT 2018

> On Jun 2, 2018, at 2:05 PM, Christian Stimming <christian at cstimming.de> wrote:
> Am Samstag, 2. Juni 2018, 08:16:35 schrieb John Ralls:
>>>> But why do we keep a "gnucash" repo at all and not only everyone's
>>>> personal
>>>> repository? Of course there is some sort of project belonging. My
>>>> proposal
>>>> is to still keep the 2.6 branch a little bit more alive, and one or two
>>>> maintenance releases might be spun off from there. I'd be the one who
>>>> does
>>>> the housekeeping there, as discussed already.
>>> Considering you do offer to take care of that 2.6 branch I can live with
>>> having one. If John disagrees you may need to make it a core policy
>>> decision request and check for a broader opinion there.
>> I disagree for the user and contributor confusion reasons already stated,
>> because I think that the old Windows build system should be retired, and
>> because I think Christian has forgotten how much work goes into support and
>> won’t have time to devote to it.
>> If Christian wants to fork GnuCash to maintain 2.6.x, he’s free to do so,
>> but it should be clear to all that it’s Christian’s fork and not “Official"
>> GnuCash. It’s much clearer and cleaner if the fork lives in Christian’s own
>> public repository with its own bug tracker and its own support mailing
>> list. It’s 10 minutes work to set all of that up on Github, so what’s the
>> point of keeping it in the Github repository?
> *sigh* Of course there is already a private fork, just as everyone else around 
> here is free to privately fork anything that he/she wants. 
> https://github.com/cstim/gnucash/tree/branch-2.6
> However, that's not the point of our common project gnucash. "Official", as 
> you call it.
> Talking of core policy decision: Ultimately the decision is about whether 
> there might be another 2.6.x release after the 2.6.20 in April, which in turn 
> is the reason for the existence of any 2.6 branch. John, it seems you decided 
> that there should not be any such release anymore under any circumstances. Had 
> this been a decision following our decision process,
> https://wiki.gnucash.org/wiki/Decision_process
> , I would have been the voice that raises a objection to that decision.
> From my point of view, April isn't too far away and there might indeed be a 
> 2.6.21 with some bugfixes. This is not a long-term commitment, just for maybe 
> another few months after the 2.6.20 release. How big is the risk in accepting 
> this objection and allow a potential 2.6.21 release to show up in the near 
> future? I'm surprised to see that prohibited from your side to begin with.


Sigh yourself.

As I pointed out before, there is no new policy. As far as I can tell from the repo's history GnuCash has *never* maintained two stable branches. Ever. We're following that practice by end-of-lifing 2.6 with the release of 3.0. If there needs to be a core decision it's to change that policy, not to continue it.

BTW, there's already a 2.6.21 because the MySQL backend was broken on 2.6.20. It was released April 10. 

How is it not a long-term commitment? There's no end to "just one more".

John Ralls

More information about the gnucash-devel mailing list