WebERP v5.0.1

[timschofield]

The webERP team are proud to announce the release of version 5.0.1. This is a bug fix version of versio 5.0 including only bug fixes, and no new features.

---

This discussion was created from the release WebERP v5.0.1.

[dalers]

Hi @timschofield, iiuc the commits for v5.0.1 (i.e. the commits in the stable-5.0 branch) do not appear in the master branch. My understanding of the release procedure is that the master branch should contain all the commits in the stable-5.0 branch i.e. the master branch should be a superset of a stable branch because a bug fix in a stable branch is also a bug fix in the master branch.

Am I misunderstanding the procedure? If I am correct, I believe the solution should be to merge the stable branch back into the master branch.

[dalers]

Iiuc stable-5.0 will always be behind master but I don't think it should ever be ahead (or perhaps at most 1 - if the "release" commit is made first in the stable branch and then after merged into master, iiuc).

I understood the commit branch rule was that commits are to be made only to the master branch. If a commit is considered 5.0 maintenance, it would then be cherry picked to the stable5.0 branch and tagged as a point release. Am I mis-understanding? (this was the most recent discussion iiuc #774 (comment) )

edit: after more thought I'm thinking it's irrelevant who is ahead or behind and by how much as it all depends on the commits that are merged. However, if I'm following the master branch because I want to be working with "the latest" code, then do I have to merge the maintenance release myself? Iiuc, this would mean the bug fix wouldn't get merged into the master branch until a PR with my feature code is merged. I think this would lead to confusing commits by entangling my feature code with the maintenance release code. WDYT? Do you agree?

[dalers]

Ideally, I think, I would like to have the confidence that the master branch I'm following does not have any of the issues that were fixed in a maintenance branch. Does anyone know how other projects handle this issue?

[dalers]

Hmm, attempting now to merge the maintenance release (stable5.0) into master is giving merge conflicts.

I think I should have first switched to my master branch (which follows @timschofield 's master branch), then pulled from @timschofield 's stable5.0 branch. Instead, I pulled into my dev feature branch (adding the "WO without BOM" feature I'm working on). However, the files listed with merge conflicts aren't files I have edited so I don't think the merge conflicts are the result of anything I've done (certainly not intentionally).

[dalers]

It seems the question is should maintenance release 5.0.1 be merged back into the master branch? Are the releases in 5.0.1 irrelevent to the master branch? Does (or will) the master branch deal with the issues resolved in the 5.0.1 release some other way?

[timschofield]

Hi Dale, all development happens in the master branch - both new features and bug fixes. In theory what was meant to happen was that any bug fixes should be committed with a commit message beginning with the word "Fix" and I have a bash script that would cherry pick those commits into the stable branch. In practice this hasn't always happened so I have had to manually cherry pick bug fixes into the stable branch. This is what has led to the strange numbers you mentioned. The only commits in stable but not in master are just those updating the version number to 5.0.1.
There is no need to merge stable back into master because it is already there.
This could have been done better, but the end result is what we want with all development in master, and just bug fixes in stable5.0. When v5.1 is released stable5.0 will be discarded in favour of a new stable5.1 branch.

Tim

[dalers]

Thanks @timschofield for confirming all the commits in the stable5.0 branch should already be in the master branch. It wasn't immediately obvious and I now understand that it's irrelevant which branch is ahead or behind, and by how many commits, as it depends on the specific commits and their purpose.

I think while your "Fix" commit message may have worked in theory, in practise it can't be depended on and manual cherry picking as you did is the only practical solution.

However, I'm still confused. Iiuc, the files in the master branch should be identical to those in the stable5.0 branch. However, at least looking at GLAccounts.php, that does not seem to be the case. In the master branch, GLAccounts.php includes GLFunctions.php to presumably access CashFlowsActivityName(), while in the stable5.0 branch, GLAccounts.php itself contains CashFlowsActivityName().

[timschofield]

Hi Dale, GLFunctions.php was added to GLAccounts.php in this commit of Ricard's - 1b9974f

Basically he moved some code that was previously in GLAcxcounts.php to a function in GLFunctions.php. This was an improvement, not a bug fix so it didn't make it to stable5.0

Tim

[dalers]

Ah, I understand now. Thanks.

[efeoli]

Hi Tim,
I already have expressed the joy of v 5.01 launching and that it is an extraordinary achievement.

Wouldn't it be conmesurate reviving Status: Closed (completed).
#218 to enhance all around image of the applicaion?

Just to inform you, the V 5.0.1 doesn't comprise the global currency improvement in the master that works very well.

Enrique

[dalers]

I created a new issue #810 for the WOCanBeProducedNow.php script

[efeoli]

Hi Dale, I am using the master despite the v 5 0.1. Tim managed to integrate a currency system showing exchange rates worldwide. If I load v 5.0.1 it is absent, but going back to the master it is just fine, This must be the case for WOCanBeProducedNow.php, since again, Tim did fix that under my request and in the master it is in the menu as Work Orders Ready to be Produced. Enrique

…

________________________________ From: Dale Scott ***@***.***> Sent: Wednesday, January 7, 2026 4:41 PM To: timschofield/webERP ***@***.***> Cc: efeoli ***@***.***>; Comment ***@***.***> Subject: Re: [timschofield/webERP] WebERP v5.0.1 (Discussion #805) I created a new issue #810<#810> for the WOCanBeProducedNow.php script — Reply to this email directly, view it on GitHub<#805 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BMM2WNGTPBTFAMWPVRJSAHL4FWRSBAVCNFSM6AAAAACQOUPAWSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNBTHE2TGMY>. You are receiving this because you commented.Message ID: ***@***.***>

[timschofield]

Hi Enrique, v5.0.1 is v6.0 with bug fixes applied. The currency system you mentioned is new functionality written after v5.0 was released so isn't in 5.0.1. It will be in v5.1.

Tim

[efeoli]

Hi Tim, Thank you for letting me know. I will be watching for 5.1. Enrique

…

________________________________ From: Tim Schofield ***@***.***> Sent: Saturday, January 10, 2026 1:34 PM To: timschofield/webERP ***@***.***> Cc: efeoli ***@***.***>; Comment ***@***.***> Subject: Re: [timschofield/webERP] WebERP v5.0.1 (Discussion #805) Hi Enrique, v5.0.1 is v6.0 with bug fixes applied. The currency system you mentioned is new functionality written after v5.0 was released so isn't in 5.0.1. It will be in v5.1. Tim — Reply to this email directly, view it on GitHub<#805 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BMM2WNEZH3DPSYE2OMD6HWT4GFV7BAVCNFSM6AAAAACQOUPAWSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNBWGUYTEOI>. You are receiving this because you commented.Message ID: ***@***.***>