[Qgis-psc] Releasing LT version monthly in the first 6 months after the release

[Jürgen E. Fischer]

Hi Andreas,

On Thu, 23. Mar 2023 at 19:03:34 +0100, Andreas Neumann via QGIS-PSC wrote:
> esp. in the light of the combination with the quarantine rule and one month
> delay that comes with the quarantine rule.

I'm still not sure about this quarantine rule - IMHO patches should be
available in the nightlies and not be hidden in some git branch.


> So Jürgen: May I please kindly ask you to adjust the road map (
> https://www.qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule)
> again - sorry about the back on forth in this respect.

I just realize that I didn't send the reply - but I did update the schedule.


On Fri, 24. Mar 2023 at 08:48:05 +0100, Matthias Kuhn via QGIS-PSC wrote:
> Re-adding the unintentionally removed conversation to the list.
> Thanks Andreas!

> On Fri, Mar 24, 2023, 08:36 Andreas Neumann <a.neumann at carto.net> wrote:
> > On 2023-03-23 23:42, Matthias Kuhn wrote:
> > I agree with you that a monthly release makes sense, especially in the
> > beginning, but I wonder if it makes sense to change that towards the end or
> > if we can just stick to the once patch release per month that we currently
> > have. Even at this stage, I think this can help.

> > That would be fine with me as well: keep the monthly releases until the
> > end of the life time of an LT version. That would probably make things
> > easier for Jürgen.

Yes, I don't see a need to lower the frequency later either.


> > As for releasing earlier for testing, I like the idea a lot but would not
> > limit it to specific people but spread it as much as possible, labeled as
> > "release candidate", 2-4 weeks before the final release to leave room for
> > reaction and possibly a second rc.

> > Ok, yes. That is also ok for me. And I think we already do that. The
> > first version 3.0 has the label "release candidate" written on the Splash
> > screen. So that is already covered. We just have to check websites and
> > other communication if we handle the "release candidate" wording
> > consistently.

That makes sense to me too.  Currently there's no means to produce secret
releases.

I could do test packages for OSGeo4W, so everyone would need to tick
Experimental, who wanted to test them, while everyone else would still get the
old version.  But if dependencies change for the new release - which is not
that unsual - that might still break the current/previous packages.

The packages for the MSIs are also fetched from OSGeo4W - so if they aren't
there that would have to be adapted too.

I could alternatively produce a qgis-rc line of packages before the release
- next to qgis/qgis-rel-dev and also package that.  But the only difference
between the regular and the nightly packages is that the regular build is
split into several subpackages and that it doesn't produce debug output.  So
there's only a small chance that things don't show in the nightlies that might
break the release.

Just coining .0 as RC as we already do is much easier.


Jürgen

-- 
Jürgen E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31
Dipl.-Inf. (FH)             Rheinstraße 13          Fax. +49-4931-918175-50
Software Engineer           D-26506 Norden            https://www.norbit.de
QGIS release manager (PSC)  Germany                 IRC: jef on Libera|OFTC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20230330/8eea3e95/attachment.sig>