Logseq is a powerful and versatile software that covers a wide range of features and combinations, making it difficult to ensure that all potential issues are identified during testing. To improve the quality of our releases, Logseq has implemented a variety of strategies aimed at identifying and addressing potential bugs before they reach the public.
Testing Strategies
One of the main strategies that Logseq uses to improve the quality of releases is the implementation of thorough testing. This includes:
Unit-testing: These tests focus on individual units of code, such as functions and methods, to ensure they work as expected.
Automatic end-to-end testing: These tests simulate real-world scenarios and test the software’s overall functionality.
Continuous Integration (CI): By integrating and testing code changes frequently, we can quickly identify and fix potential issues.
By continuously adding tests for the software’s GUI, Logseq developers are able to identify potential issues before they reach the public.
Nightly Builds
Another strategy that Logseq uses to improve the quality of releases is the use of nightly builds. The nightly build is a daily build of the master branch, which serves as a way for alpha testers to identify potential bugs the day before a release. If a bug is found in a nightly build, Logseq has a light process in place to quickly patch the bug without delaying the release.
Versioning
It’s worth noting that Logseq’s versioning system may differ from the Semantic Versioning (SEMVER) standard before reaching version 1.0.0.
Summary
It’s important to note that there is always a trade-off between speed of development and stability in software development. Logseq understands this, and while we strive to improve the quality of releases, we also need to balance that with the cost of development.
Logseq is committed to improving the quality of our releases by implementing thorough testing strategies and utilizing nightly builds. We are continuously working to strike a balance and deliver the best possible software experience to users.
The problem is that the nightly build approach is letting lots of fairly big bugs through which actually affect people’s ability to use the software. I’m not sure it makes sense to wait till version 1.0 to address the needs of these users? A lot of people are already using Logseq daily for their work and want more stability reliability. To acknowledge this, it might be good to divide the beta releases into “testing” and “stable” branches, so that people can choose whether to be on the bleeding edge or not. Those who want to engage in testing can use that channel as well as testflight on iOS. Those who just want to work until the bugs are fixed can use the stable/app store channel. I think such an approach would address many of the concerns over stability I’ve seen users bringing up in the forums and on Discord.
Also it make sense of having more documenting on the roadmap items. But as we are in beta and don’t have a “release candidate” process, it’s hard to expect “what to have in next release”, compared to those with the process of doing rc
Maybe it’s near to the time point to have a rc process.
Establishing rc process would occupied some bandwidth on code merging with conflict resolution, and require dedicated test user pool for QA on the release candidates. We will evaluate on this.
(It’s not that great having similar discussion in different threads. We may leave the further discussion about releasing & roadmap here @laike9m )