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

Sun Jun 3 01:02:36 EDT 2018

Folks,

Perhaps my comments are not wanted, or out of place, but as an active user, someone who contributes a bit of assistance on the mailing list, and just someone who in general helps people less knowledgable with software selections and support, I have to ask, “Christian, did you consider the impact on complete newbies who might stumble upon and install, for whatever reason, the 2.6.x branch?” Or even someone who is still running it and contemplating an upgrade? As someone who helps out mom and pop businesses adopt GnuCash, the prospect of installing a full major version behind, bugs and all, less functionality, et cetera, and WASTING their time would leave me and them, nothing short of extremely perturbed when we eventually find out there is a more recent version. (*I* know now, but *they* won’t and they might not find me until afterwards, and what of others like me just entering this journey?) Sure, *I* can see where it would be ’nice’ to maintain an older version for certain ‘cut-off’ compatibility reasons, but those *are* the reason for a fork. (really, though, your initial stated reason was a compiling problem, which I though John answered adequately) I sure don’t want to have to repeatedly explain to people that 2.6.x is not supported if there is an ‘official’ branch in the Git repo available. (not that newbies would be looking there mind you, but one thing I’ve learned with this project is you can’t count on what you expect from how people ‘find’ you or install the software.)

I’m not a dev so I have a less than important perspective, but perhaps you should be aware, that there are some out here who aren’t devs who would not be appreciative of more than one official version that wasn’t actually an actively and officially supported version. I don’t know of any software project where that is acceptable. (If it isn’t supported, it isn’t ‘official’) It isn’t a matter of what is possible that can function or not, it’s a matter of expectation of what is supported and what isn’t. If the main devs don’t want to, or don’t have the resources to, support more than one version, then the answer is a fork. Please consider you might be making life unpleasant for more than just whatever you are willing to take one. You are obligating many others and you are creating an expectation you can’t even fully scope, much less fulfill. (or even at least initially be called to fulfill) Others are going have to have to deal with this ‘old version’ for as long as it exists, not just you.

Regards,
Adrien

> On Jun 2, 2018, at 7:28 PM, John Ralls <jralls at ceridwen.us> wrote:
> 
> 
> 
>> 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.
> 
> Christian,
> 
> 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".
> 
> Regards,
> John Ralls
> 
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel