<html><body><div><div><span>Hello Jurgen et. al.</span></div><br><div><span>Following the earlier conversation. With the 3.28.12 point release on the horizon, is there a date where we can start testing the LTR nightlies assuming that there will be no significant changes either in the LTR code or in the dependencies that will be used? Or this condition can only be assumed in 27-10-2023?</span></div><br><div><span>Thanks,</span></div><br><div><span>Alexandre Neto</span></div></div><br><div><div>On Thu Sep 21, 2023, 11:10 AM GMT, <a href="mailto:senhor.neto@gmail.com">Alexandre Neto</a> wrote:<br></div><blockquote style="margin:0 0 0 4pt;padding-left:4pt;border-left:1px solid #CCC"><div><div dir="ltr"><div dir="auto"><div>Hello Jürgen, Mathias et al.,</div><div dir="auto"><br></div><div>Seems I forgot to answer this thread many moons ago. Sorry for the inconvenience.<br></div><div dir="auto"><br></div><div dir="auto">The manual testing idea is to be focused on the LTR releases only, where there is no .0 RC, but it will still be affected by backports and updates to the dependencies (correct me if I am wrong).</div><div dir="auto"><br></div><div dir="auto">It's not supposed to make things harder for anyone , so, if the PSC agrees, I would be happy to test the qgis-ltr-dev-full (LTR nightlies) just BEFORE they become ltr-full on OSGeo4w. The msi can be tested later.</div><div dir="auto"><br></div><div dir="auto">For that, what I would ask is a kind of LTR nightly freeze once it's ready for final packaging (no more backporting fixes or dependency bumps if possible), for a period of at least a week (maybe this happens already?).</div><div dir="auto"><br></div><div dir="auto">It was never intended to be of secret access, nor only for specific people. The more people test it, the better!! But IMHO, it shouldn't be done by accident by final users in production that received a warning to update their LTR or that just happen to have QGIS Roadmap in their desk and are trying to get the new LTR version as fast as possible. People using qgis-ltr-dev-full will know what they are using and the risks.<br></div><div dir="auto"><br></div><div>I think what Andreas wanted was to run test cycle on LTR patch releases on versions .4 (the LTR release premier), .5, .6, .7, .8 (new stable release), .12 (another stable release). Am I correct?<br></div><div dir="auto"><br></div><div>Thanks and again sorry for the huge delay.</div><div><br></div><div>Best regards,<br></div><div dir="auto">Alex Neto</div><div dir="auto"><br></div><div dir="auto"><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">A quinta, 30/03/2023, 11:04, Jürgen E. Fischer via QGIS-PSC <<a href="mailto:qgis-psc@lists.osgeo.org">qgis-psc@lists.osgeo.org</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Andreas,<br>
<br>
On Thu, 23. Mar 2023 at 19:03:34 +0100, Andreas Neumann via QGIS-PSC wrote:<br>
> esp. in the light of the combination with the quarantine rule and one month<br>
> delay that comes with the quarantine rule.<br>
<br>
I'm still not sure about this quarantine rule - IMHO patches should be<br>
available in the nightlies and not be hidden in some git branch.<br>
<br>
<br>
> So Jürgen: May I please kindly ask you to adjust the road map (<br>
> <a href="https://www.qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule" target="_blank" rel="noopener noreferrer">https://www.qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule</a>)<br>
> again - sorry about the back on forth in this respect.<br>
<br>
I just realize that I didn't send the reply - but I did update the schedule.<br>
<br>
<br>
On Fri, 24. Mar 2023 at 08:48:05 +0100, Matthias Kuhn via QGIS-PSC wrote:<br>
> Re-adding the unintentionally removed conversation to the list.<br>
> Thanks Andreas!<br>
<br>
> On Fri, Mar 24, 2023, 08:36 Andreas Neumann <<a href="mailto:a.neumann@carto.net">a.neumann@carto.net</a>> wrote:<br>
> > On 2023-03-23 23:42, Matthias Kuhn wrote:<br>
> > I agree with you that a monthly release makes sense, especially in the<br>
> > beginning, but I wonder if it makes sense to change that towards the end or<br>
> > if we can just stick to the once patch release per month that we currently<br>
> > have. Even at this stage, I think this can help.<br>
<br>
> > That would be fine with me as well: keep the monthly releases until the<br>
> > end of the life time of an LT version. That would probably make things<br>
> > easier for Jürgen.<br>
<br>
Yes, I don't see a need to lower the frequency later either.<br>
<br>
<br>
> > As for releasing earlier for testing, I like the idea a lot but would not<br>
> > limit it to specific people but spread it as much as possible, labeled as<br>
> > "release candidate", 2-4 weeks before the final release to leave room for<br>
> > reaction and possibly a second rc.<br>
<br>
> > Ok, yes. That is also ok for me. And I think we already do that. The<br>
> > first version 3.0 has the label "release candidate" written on the Splash<br>
> > screen. So that is already covered. We just have to check websites and<br>
> > other communication if we handle the "release candidate" wording<br>
> > consistently.<br>
<br>
That makes sense to me too. Currently there's no means to produce secret<br>
releases.<br>
<br>
I could do test packages for OSGeo4W, so everyone would need to tick<br>
Experimental, who wanted to test them, while everyone else would still get the<br>
old version. But if dependencies change for the new release - which is not<br>
that unsual - that might still break the current/previous packages.<br>
<br>
The packages for the MSIs are also fetched from OSGeo4W - so if they aren't<br>
there that would have to be adapted too.<br>
<br>
I could alternatively produce a qgis-rc line of packages before the release<br>
- next to qgis/qgis-rel-dev and also package that. But the only difference<br>
between the regular and the nightly packages is that the regular build is<br>
split into several subpackages and that it doesn't produce debug output. So<br>
there's only a small chance that things don't show in the nightlies that might<br>
break the release.<br>
<br>
Just coining .0 as RC as we already do is much easier.<br>
<br>
<br>
Jürgen<br>
<br>
-- <br>
Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31<br>
Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50<br>
Software Engineer D-26506 Norden <a href="https://www.norbit.de" target="_blank" rel="noopener noreferrer">https://www.norbit.de</a><br>
QGIS release manager (PSC) Germany IRC: jef on Libera|OFTC<br>
_______________________________________________<br>
QGIS-PSC mailing list<br>
<a href="mailto:QGIS-PSC@lists.osgeo.org">QGIS-PSC@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc" target="_blank" rel="noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a><br>
</blockquote></div></div></div>
</div>
</div></blockquote></div></body></html>