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.