3 Tribler Releases / Branches

[Dmole]

Many Tribler releases introduce fatal new bugs.

As Tribler is clearly missing automated testing (many VMs sequentially on one cheap box)

Please adopt main/testing/release branches and builds so bugs can be squashed before hitting the the main download on tribler.org.

example bugs:
7.7.0 - crash on exclude files
7.6.1 - "max node" popup
7.5.2 - crash om load with GLIBC_2.29' not found
7.5.0 - infinite loop on large torrent
7.5.0 - no documentation for API change
7.5.0 - removal of headless API
... and many (~2841) more.

Very few if any releases are bug free. A stable branch is long overdue IMO.

devos50 said some internal discussion would happen so here is a public reminder.

[Shidouuu]

+1
Definitely not enough experimental releases. Stable releases should be every 3 months; 1 month isn't enough for testing.

Something like Pylance which comes with the python extension in VSC would prevent a lot of these bugs, like in 7.7.0 where a simple type error that crashed the entire program whenever you loaded a new torrent with no anonymity could've been prevented if the error were highlighted.

[synctext]

We indeed need to do a better job on bug fixing.

We are doing quick releases to maximize progress on Tribler. We have invested a lot of time in automated testing and deployment monitoring. This should start to pay-off soon with good quality code. Basically our code should never be 'unstable'.

[Dmole]

We are doing quick releases to maximize progress on Tribler.

That is not mutually exclusive; just have every release go through a 1 week beta, fixing and re-building as bugs are reported, then mark the release as stable. The whole point of git is cheap branching/merging/etc.

We have invested a lot of time in automated testing and deployment monitoring.

Adding a code-coverage metric would quantify if that time payed off. But you need not invest at all; just let users do the beta testing.

Basically our code should never be 'unstable'.

It currently (7.7) is 'unstable' while advertised as 'stable' on tribler.org thus this issue.

[Dmole]

So 14 days ago we had a V7.8.0-RC1 but then instead of making it a release a few days later, 2 hours ago V7.8.0 was released with a long change log and without any user testing. All non-RC builds should have a 1 item change log "released"... guess I'll go check for bugs after the fact.

[xoriole]

@Dmole We understand your concern. We do not want to ship a buggy release as well. In the last two weeks of RC release, we did not receive any critical bug reports, so we're releasing a stable version today. The urgency is also because 7.8.0 includes an important fix to a memory leak issue so we want to get this out there quickly.

Regarding the changelog in the release page, it lists the changes since the last stable version (7.7.1), and not the latest RC (7.8.0-RC1). The actual difference from the lastest RC is very small and also tested.

[Dmole]

@xoriole from 7.8.0-RC1, v7.8.0 "Showed token balance again" without fixing any of component: token economy

[xoriole]

@Dmole That commit is part of a PR that was added since RC1. The token balance display was hidden earlier because of a bug that caused users to have insane balance. Now that bug is fixed and the balances are wiped so it was added back. It should not affect the normal Tribler usage.

[Dmole]

So we agree the release was not done properly because

All non-RC builds should have a 1 item change log "released"

or are you saying that a release should contain commits that were not in the RC?
That's a rhetorical question; I'm just trying to thank contributers by providing some unsolicited thoughts on best practices effecting user adoption. :)

[xoriole]

@Dmole Thank you for the feedback

[qstokkink]

Starting from the 8.0 release, we will adopt a different branch management process with more frequent releases.