Desktop team released RC3 for 3.5

šŸ“° News
1

Hi all,

The subject says it all - RC3 is here, weā€™re looking forward to your feedback! The release is delayed a bit as weā€™re trying to get one more feature in, so expect the final in ~3 weeks. Testing continues to be helpful, though, as weā€™d like it as stable as possible of course.

Changes:

Get builds for Windows, Mac and Linux here: Release Release 3.5.0 RC3 Ā· nextcloud/desktop Ā· GitHub

2

Thanks for the great work!

I just would like to mention bug Sync Pending - Windows 10 Ā· Issue #4226 Ā· nextcloud/desktop Ā· GitHub which exists since quite some time and is still present with this RC3.

3

@bug-hunters help test the desktop release client rc3 for 3.5

4

@jospoortvliet this is still an issue on 3.5 RC3. This should be something that the desktop team should fix soon as alot of people use the word files and im sure not everyone wants to see sync icon all the time when its not syncing.

5

Hi everybody,

Thanks for testing and for your feedback!

As for the bugs that were mentioned here, these are serious, but not bugs that were not present in previous releases - only such regressions block releases. Otherwise weā€™d never be able to do a release as thereā€™s always something broken in some scenario somewhereā€¦

6

Thatā€™s Nextcloud policy, is it?

Serious bugs arenā€™t a bar to release, unless theyā€™re regression bugs?

7

Yup. Thatā€™s the only sane release policy any company or project can have. Regressions block releases - you donā€™t want to release something thatā€™s WORSE than what you had before. Better is the goal. Perfect would be nice but in reality of course perfect is impossible, so lack of perfection shouldnā€™t be a blocker for releasing something thatā€™s better than what you have.

8

This policy seemā€™s insane, right.

But it is called XP programming and is quite common in software industry:

  • regression are bare for release
  • new version are released with new functions and new bugs ex: v1.2.784
  • new bugs are dealt with.
  • New release is done if no regression are found with old functions. ex v1.2.785
  • regression are bare for release
  • and so onā€¦

And sometime, a new major version is set: ex v 2.0.1
ā€¦ and so on

The release pace is fast, no regression in apps, new app, and bug fixā€¦ within the same released major versionā€¦
Also, XP programming is used when you have several devel entity, or sub-projects ā€¦

Usually the numbering is V.S.R

  • Versioning
  • Stepping
  • Release
9

No, that is very definitely not the only policy. You might consider that any release with serious bugs is not good enough.

When I worked on big software projects, we would never release anything with serious bugs. Our software was mission-critical and had to work properly. We released new versions when they were ready, not to a schedule

Iā€™m not saying that this should be Nextcloud policy (though I wish it was) but I AM saying that it is a valid alternative.

10

Iā€™m not disagreeing with you, if the client would eat data in common scenarioā€™s, weā€™d stop all the presses and fix it. But it does not - otherwise, millions of users would not be using it happily. The bugs that exist might be major to a few people but not to the vast majorityā€¦ I donā€™t think @stratege1401 would suggest that ignoring such huge issues is part of an XP release policy, either.

So it depends on your definition of ā€˜major bugā€™. If it is ā€œsomething that blocks a majority of users from using the appā€, then yes, weā€™d fix that. But we wouldnā€™t even start a major release cycle without fixing such a thing first - by the time weā€™re in RC stage, we are not aware of any such major bugs.

And I know some of the issues mentioned here seem serious, but they must be hitting a small minority of users. We have customers with many millions of users using our client, and we fix bugs they report with priority. They seem to not bump into those bugs - which seems unlikely if the bug would be so common. So, weā€™ll try to fix those issues when we have time - or when a volunteer gets to it, of course - but weā€™re not holding off on a release for them.

I hope this helps explain the development process and priorities a bit. Please understand we have limited resources and if we donā€™t do releases with features people need, less people will use our product, less volunteers will help and less people pay us, and development comes to a haltā€¦ We have to balance the needs of everyone here. Believe me, neither me nor the developers are happy with open bug reports. Weā€™d much rather fix them. But we simply lack time and resources to fix everything - and that is, sadly, quite normal. Even Microsoft and Google release software with known issues, and while their millions in development funding mean only very obscure issues make it through, their large user base still means there are probably even more users affected.