Stable branch

[timschofield]

I have released version 5 earlier on - #772

I have created a stable5.0 branch which I intend should be 5.0 with any bug fixes applied. I am defining a bug as

• Critical Security Vulnerabilities - SQL injection, XSS, authentication bypasses, etc.
• Data Loss or Corruption - Issues that cause incorrect calculations, lost records, or database corruption
• Application Crashes - Fatal errors, uncaught exceptions, or complete application failures
• Core Functionality Broken - Essential features that don't work at all (invoicing, payments, etc.)
• Regression Fixes - Bugs introduced in the last release that break previously working functionality

The following do not count as bugs

• New Features - Even small ones, even if they're "just configuration options"
• UI/UX Enhancements - Layout improvements, styling changes, workflow optimizations
• Performance Optimizations - Unless they fix a critical performance regression
• Code Refactoring - Code cleanup, reorganization, or standardization
• Documentation Updates - Unless directly related to a critical bug fix
• Minor Bugs - Issues that have workarounds or don't significantly impact operations
• Deprecation Warnings - PHP warnings about deprecated features (unless they prevent operation)

When in doubt, ask: "If I deploy this to production today, would it fix something that's actively causing problems
for users, or would it just make things better?" If the latter, it goes to master, not stable.

All development should go to the master branch. If it is a bug fix, then keep the commit separate, don't mix it with development work. Also if it is a bug fix then PLEASE start your commit message with the word 'Fix'.

It is my intention to release 5.0.1, 5.0.2 etc from this branch

Thanks
Tim

[pakricard]

Congratulations to all of us ;-) It has been long, but worth it!
Thanks to @timschofield for resurrecting the project.

R

[dalers]

I feel there is a great future ahead for webERP!

@timschofield Regarding which branch to issue a PR to, a simpler description might be "only PRs to the master branch will be accepted and, if a bug fix, will be cherry picked to the stable5.0 branch.". This seems more in line with your comment #763 (comment) iiuc.

[timschofield]

Regarding which branch to issue a PR to, a simpler description might be "only PRs to the master branch will be accepted and, if a bug fix, will be cherry picked to the stable5.0 branch.".

This is what I intended to convey, except the commit message for the bug fix must start with the word "Fix"

I am trying to write some documentation for this, but I have a lot on right now.

[pakricard]

@timschofield :

I tried to “help” a couple of days ago, cherry-picking some commits from the master branch to the stable 5.0 one, and I messed up. My commits (regarding GL Cash Flow labels) did not pass the GitHub tests.

The problem was something to do with phpunit (even if this commit is posterior to the Cash Flow ones), but I think now I managed to cherry-pick the right commit from master, and now stable seems OK. Please check.

Anyway, I think we did not follow strictly the guidelines you posted on the first post regarding what deserves to be in stable 5.0 and whatnot. Should we publish a 5.1.0 version, then?

R

P.S.: I realized I won't be messing up with stable again ;-)

[timschofield]

Hi Ricard, I was trying to backport some fixes into stable myself and ran into some issues. I find cherry-pick a difficult command to work with. We seem to have more commits than I thought we had since 5.0.0 so I would be happy to do 5.1.0 if you are in agreement. I would like to keep very regular releases anyway to boost our visibility.

Tim

[dalers]

I would like to keep very regular releases anyway to boost our visibility.

Tim, assuming you are referring to point or major releases (not bug fix or security releases), I would respectfully disagree believing users would appreciate a well-tested quarterly or semi-annual release cadence more for reduced effort and increased confidence.

Releasing often could actually drive potential users away by seeming chaotic and creating more work for them (not to mention for the dev team). Quarterly or semi-annual well tested releases will boost user confidence in the project which imho will result in greater and longer lasting value than releasing more often in an attempt to boost visibility. Imho boosting visibility is best done by "getting the word out" to appropriate user communities (e.g. small businesses and startups).

If users want new features sooner, they will need to follow the master branch (which may only be temporary, until the next point release after which they can switch back to the stable branch).

It may be useful to consider how other projects manage their release process, such as the FreeBSD operating system (which I use instead of Linux in part because of its release process). The FreeBSD project has more people than we do (although fewer in admin roles than you likely think) but the concept and roles apply just as well imho to the webERP project.

Paraphrasing from https://docs.freebsd.org/en/articles/freebsd-releng/

FreeBSD utilizes a structured, time-based release engineering process, typically issuing new stable releases every 4 months, led by the Release Engineering Team. The process involves a 70-80 day ramp-up, featuring code freezes, MFC (Merge From Current) sweeps, and multiple alpha/beta snapshots to ensure stability before final release.
The structured, branch-based workflow transforms the "bleeding-edge" development code into stable, production-ready releases.

1. Branching Strategy

Development happens across three main types of branches:

• CURRENT (main): Where all new features and disruptive changes are first committed.
• STABLE (stable/X): Branched from -CURRENT every few years. It receives tested features merged from -CURRENT (a process called MFC or Merge From CURRENT).
• RELEASE (releng/X.Y): Created shortly before a final release. Once branched, only critical security and bug fixes are permitted.

2. The Release Cycle Phases

A typical release cycle (for a "point" release like 14.1) spans roughly 70–80 days:

• Code Slush: A period where developers are encouraged to prioritize bug fixes over new features. Explicit approval for commits is not yet required.
• Code Freeze: All commits to the target branch now require explicit approval from the Release Engineering Team.
• BETA Phase: The first BETA1 images are built from the -STABLE branch. Public testing begins, and at least one new BETA is typically released every one to two weeks.
• Release Candidates (RC): Once major issues are resolved, the releng/ branch is created. Images built from this branch are labeled RC1, RC2, etc..
• Final RELEASE: When an RC is deemed stable, it is tagged as the final RELEASE.

3. Key Responsibilities

The Release Engineering Team oversees several critical tasks:

• Scheduling: Setting and publishing the Release Schedule ffor the entire community.
• Change Review: Acting as a gatekeeper during code freezes to decide which patches are safe for inclusion.
• Build & Distribution: Coordinating with the Ports Management Team to ensure binary packages are ready and publishing installation media to mirrors.
• Security Handoff: Roughly two weeks after a release, authority over the releng/ branch is handed to the FreeBSD Security Team for long-term maintenance.

[pakricard]

I am OK with a 5.1.0 now.

@dalers : Your proposal looks good, but we have to be realistic. We are now a tiny (but strong) group of developers, and we do what time allows us. This proposal seems to me like a time-consuming task, probably due to ignorance, if some tasks could be automated.

R

[dalers]

we have to be realistic

@pakricard I completely agree with you and did not mean to imply the webERP project should copy FreeBSD's release process.

The basic point I was attempting to make was that I don't agree there should be more releases in an attempt to increase project visibility because we are a small group of developers with limited time.

• releasing more often will require more time to create more release commits
• releasing more often will require more time to test more releases
• creating a release without being able to credibly prove stability and correct behavior is less a "release" than a "hope" and a "release" with issues can be more damaging to the credibility of the project than no release.

I described the FreeBSD release process only as an example of a well defined release process that could give guidance to creating our own process.

[timschofield]

@dalers @pakricard

I think I probably didn't express myself very well here. I certainly wasn't proposing that we move to a permanent 3 monthly release cycle, just that we do 5.1 3 months after 5.0. Releasing v5 gave us a boost in terms of visitors to the web site, and I was thinking that backing that up with a v5.1 now might also give us a similar boost.

I would love to have a more formalised release schedule, but realistically I know I'm not the right person to manage it. Other projects I have been involved in have had a dedicated release manager who has coordinated all of this work. It is not a job involving coding, and I would be very happy for any volunteers to come forward :-)

Tim