[QGIS-Developer] Early 3.4 point release?

[Matthias Kuhn]

On 10/31/18 11:08 AM, Alessandro Pasotti wrote:
> 
> 
> On Wed, Oct 31, 2018 at 10:41 AM Giovanni Manghi
> <giovanni.manghi at gmail.com <mailto:giovanni.manghi at gmail.com>> wrote:
> 
>     > This code freeze period will need to be associated with a strict
>     definition of "blocker issues" that really need to by adressed
>     immediatly. This issue here is a great example of a valid blocker.
> 
>     big fan of the "no known regressions admitted", at least for LTR
>     releases.
> 
> 
> The problem here is the "known" part: if we had more testers on the
> nightlies during the two weeks before the release date, we would
> probably have catched some of these regression in time to fix them.

Agreed, the more testing the better.

> I think that it would be a good idea to create a group of volunteer
> testers, like we have for translators, that can regularly run test
> cycles (for example going through the tutorials that we already have)>
> 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.

I like the concept of a "release candidate".

I think by labeling a package as RC we will encourage people to

 - download and test the application
 - not use them in production
 - be relaxed about issues (because they are expected)
 - as a nice side-effect, it's also a good point in time for rolling the
   drums about an upcoming LTR.

Either we call the LTR x.y.0 version a RC (instead of the first release)
- or the 4 last weeklies before the release are labeled as RC.

But still then there will be issues and most people will only start
testing the final release and we will run into "unknown issues" and
"unreported issues" while working on QGIS and fix and push them without
a big admin overhead. And we just have to accept that this is our life
as software engineers and we all do the best we can :-)

> 
> That said, I think that "release early release often" is still the best
> way we can handle release cycles.
> 
> -- 
> Alessandro Pasotti
> w3:   www.itopen.it <http://www.itopen.it>
> 
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>