search

maticnetwork / bor

Official repository for the Polygon Blockchain
https://polygon.technology/
GNU Lesser General Public License v3.0
1.01k stars 488 forks source link

Stop pushing bugfix releases as BETA #1278

Closed sammy007 closed 4 months ago

sammy007 commented 4 months ago

This is misleading versioning and such practices must be abolished.

The following release notes are not BETA, they are minor bugfix releases. You didn't introduce anything new which requires some testing: Bor v1.3.4-beta is a maintenance release && Bor v1.3.4-beta2 includes fix to an issue.

It's 1.3.4 and 1.3.5 or even 1.3.4.1 but it's nowhere near BETA release.

Please tag anything new and meaningful as BETA. Nobody will even consider updating until there is a release given the overall instability of the software.

feld commented 4 months ago

It's more than just a bugfix though; they're merging in a lot of changes from a newer geth release and you have to be careful due to the changes Polygon/bor has made

sammy007 commented 4 months ago

Great, so no fixing bugs unless you take risk? There must be 2 branches then.

manav2401 commented 4 months ago

Hey @sammy007, I'd like to clarify our release and testing process and why we choose to do it this way.

Our every release goes through multiple phases in testing starting from devnets to testnet to mainnet. This means that there are multiple phases of deployment as well.

Every new release e.g. v1.3.3-beta either introduces new features or has some major changes / improvements to previous version (i.e. previous stable version 1.3.2). It also includes changes from the upstream merge from geth (if any). Devnet testing only gives us a limited amount of confidence and hence we need to test them on actual production nodes. As we do run quite a few nodes internally, our internal deployment process is based on packaging. Simply put, deployment can only happen based on a specific bor/heimdall package which are generated when we do a new release (see the assets section of any release). These changes are deployed on testnets (amoy network) and is observed for few days. During this time, we keep an eye on bug reports which might be introduced in this new version. If any, a new beta version is released to fix them. On sufficient confidence, we deploy the latest beta version on our internal mainnet nodes and again wait and observe. Once we are confident enough, we make a stable release (e.g. v1.3.3) which we later inform to external operators and mark it as a latest release on github making it stable for public use.

So, the first beta release is not just a bug-fix but also a feature release. It's marked as beta because it's not fully tested on production environments and hence we don't recommend deploying them unless you're sure of what are the new changes. We're currently working on generating packages from custom branches which will make our internal deployment easier without making any public release (which are only supposed to be for internal deployment as of now). Once that is in place, the beta releases would probably go away. Until then we'd like to stick to this process. If you still have any concerns or points for improvements, let us know. We'd be happy to take a look. Thanks :)