On 10/31/2018 11:08 AM, Alessandro Pasotti wrote: > We might want to introduce the concept of release candidate, in order to > have a stricter code freeze, and give the testers and translators some > amount of time for testing and translations, during this time only "real" > bug fixes should be allowed. > > That said, I think that "release early release often" is still the best way > we can handle release cycles.
I'm also +1 for release early and often in the pace we do now. I think FOSS depends on users. If you have are a commercial company you can pay testers (who create test scenario's etc etc).. costing a lot of money. We have users who test, and yes, they do mostly around (after?) release... So: release often. And I DO test (and compile) all the time (almost daily compiles). Off course more testing would maybe make some(!) issues be fixed before a release. And we DO have a 'feature freeze' in which we should ( try to ;-) ) only fix bugs (as if it was a RC). So adding another RC is only theoretical/administrive in my view. We could be more strict though... Bugs like the one above can always be introduced even when we had a RC. That is one of the drawbacks of compiling for so many platforms (with so many versions of needed libs....). But that is also our strength! Anyway, before releasing 3.4.1 please can other check/confirm this one: https://issues.qgis.org/issues/20295 Regards, Richard Duivenvoorde _______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer