Quote:
Originally Posted by Agama
or define the notification as an integer: "How many releases to wait before notifying", so
0=Do Not Notify,
1=Notify every release
2=Wait for 2 releases
:
5=Wait for 5 releases
etc.
|
How is waiting N releases going to help anything? For example, 0.7.36 had several regressions, fixed by 0.7.37. Someone who is waiting two releases would pick up the broken one when 0.7.38 is released. This would not be good.
What this thread is really asking for is for 'someone' to declare a given release stable and suitable for general public. 'Someone' must use intelligence. 'Someone' would need to decide on a release-by-release basis whether that release is suitable for the masses, then somehow propagate that information (how?). The same 'someone' would probably need to redo change logs to redact information about regressions and their repair. And 'someone' would get into the 'known problems' arena, listing new releases with the problem they fix and the problems they create.
Calibre is updated weekly. Things get added, and things get (usually unintentionally) broken. If people don't want to be exposed to that process, then turn off update notification. Personally, I have no objection to following toddos' suggestion: turning it off by default, but that is probably too radical a solution.
Note that we tried a beta program with the 0.6 to 0.7 transition. We had some testers and their input was invaluable, but it was nowhere near sufficient. When 0.7.0 came out there was a firestorm of complaint, mostly justified, sometimes not. A couple of times since I have tried to do betas, with almost no take up. I have found that the only way to get more than a small group of usual suspects to test something is to release it.