Hotfix, version-XX, develop : issue, PR and Frappe policies

Hello all,

I’m gona be a little salted in this post, but it’s with gentle word and in hope get some point of view from other developers and may be Frappe feedback.

To not be sterile in my purpose I’ll give an example.

I found a bug in version-12 (already known on this forum but no issue on Github)
So I created the issue : Issue 26828

And I worked on it to try to find a way to fix it
3 PR : on version-12-hotfix : version-13-hotfix, develop

Two PR closed version-12-hotfix, version-13-hotfix because, there is some other way to do it in develop branch… I can hear and adapt, and I’m happy with PR review process. But, according to Frappe, it is better to first fix in develop branch, that is not actually use in production by anyone, and backport on version-13-hotfix and version-12-hotfix rather than fix in version-12-hotfix and merge fix in upper version ?
I will prefer the other way, existing bug in current version is much more important than in develop branch. Close PR on develop and ask to fix it in better way on 12 and 13.

On the requested change for this PR on develop branch, I was ok, my first solution was a little express, I’m not specially proud of it, but it was correct regarding code above and lower, and also fix the bug.
The solution required by PR reviewer is not the same way code is already wrote, it do not use parameters already use upper and lower in the code… I submit my code too fast, but reviewer write review too fast also ?

The fact that a bug fix in version-12 is not “automatically” merge into upper version is very strange. It’s like each version of ERPNext is a new software. “Don’t look the past, always going to the future”… People use ERPNext in production, for their own company, we cannot secure software with this way of doing things.

I come from other open-source ERP/CRM community, and it’s not the case, fix in one version is carefully “upport” in next version by maintainers (just merge with git). And all maintainers of the other project aren’t paid for that, in but in Frappe there are peoples employed for that.
The fact that version-12 cannot be merge in version-13 and version-13 cannot be merge in develop is just “to my humble point of view” a non sense.

Other subject, the test coverage is not complete (43% actually) and as I look at some fix PR where PR reviewer ask to the author to write test case before merge the PR (Issue 26320 , gratefully the PR finally merge and PR reviewer finally write the missing test case, as it should be done from the beginning by a company that is the software editor of the project.

So what should we expect for our fix contribution ? (I’m not talking about new feature here just fix)
Frappe take time to make merge lower to upper version working and open a way to manage to upport fixes correctly, or we just continue to struggle with multiple PR and It’s just like that and that it, take or leave.

  • Sending PR to develop or main is common development practice. Only fixes are backported to the production version. Once the main PR is merged, the backport usually doesn’t take much time, hence the order in which changes are merged is not consequential.
  • We are working on auto-backporting: GitHub - frappe/backport: backport automation @ frappe If your contribution is small and can be squashed, don’t bother about backporting it yourself, just leave a comment and the reviewer will take care of it. If your contribution is huge and will require manual backporting (due to conflicts or multi-commits) then send separate PRs.
2 Likes

Thank you very much for this answer.
It’s so much clear for me now, this answer reassure me into the fact that Frappe team take care of their product.

So I have to make a process to have tree test environment on 12, 13 and develop, and make a migration process easy/automated to be sure that a bug find in 12 is still there in upper version.

There is a change in timing on release version of ERPNext, I see now that every week there is a new release of ERPNext (and Frappe) for version-13.
Could you correct me if I’m wrong but what I guess :
version-XX-hotfix merged into version-XX-pre-realease merged into version-XX ?

But imagine, I want to deploy fix before “official” release so I switch to branch version-XX-hotfix or version-XX-pre-realease, but In these branch the erpnext/erpnext/__init__.py the __version__ = "13.2.0" as in version-XX it’s (currently) __version__ = "13.24.0"

The version change in __init__.py is only in version-XX just before release version.
Will it be a good practice to merge back version-XX into version-XX-pre-release and version-XX-hotfix just after release to have the branch with the good version number into __init__.py ?

1 Like