On Wed, Jan 12, 2022 at 4:52 PM Vaclav Petras <wenzesl...@gmail.com> wrote:
>
> On Tue, Jan 11, 2022 at 12:52 PM Veronica Andreo <veroand...@gmail.com> wrote:
> >
> > El dom, 9 ene 2022 a las 16:36, Markus Neteler (<nete...@osgeo.org>)
> > escribió:
> >>
> >> Can we now publish "final" or do we still need a RC2?
> >
> > With no blockers, I'd be in favor of publishing final already :)
> > Is there any "policy" regarding the number of RC's before final?
>
> Traditionally, I think we did 2 RCs, but since we are releasing from a
> ("stable") branch rather than the main (development) branch, one could argue
> we don't need any RCs at all. Perhaps 8.0.0 and all x.0.0 would be an
> exception requiring one RC since the branch is new(ly created from the main
> branch).
In this actual case I suggest to check what actually changed after RC1:
# go via "tag"
https://github.com/OSGeo/grass/releases/tag/8.0.0RC1
--> 19 commits to releasebranch_8_0 since this release
--> https://github.com/OSGeo/grass/compare/8.0.0RC1...releasebranch_8_0
--> list of changes
> We have a RFC with two RCs [1], but I think since then we considered reducing
> that (I can't find the wiki page with the notes).
>
> [1] https://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure
It is still:
Status: Late draft (7 Jan 2015)
so we may adapt and approve it in the PSC.
> On Tue, Jan 11, 2022 at 1:39 PM Newcomb, Doug via grass-dev
> <grass-dev@lists.osgeo.org> wrote:
> >
> > There may be some work to be done on the Windows standalone installer yet.
>
> At the New Year's call, we discussed a little bit that with a release, we may
> focus on the source code readiness for a release, but more or less ignore the
> distribution of the software. In other words, we would leave out the
> complexities of distributing the software from the event of tagging the
> source code with a release tag. On the other hand, the Windows installer code
> lives in the main source code, so as a result any changes may trigger a new
> patch release if we ignore the standalone installer when tagging. In any
> case, small issues in the installer are not blockers of the release.
>
> In an ideal world, the Windows installer is built automatically based on the
> event of tagging the release and the same happens for each commit on the
> branch for testing purposes. This can be achieved with the installer code in
> the main repo or in the separate repo in case a separate repo would clear up
> some issues with releasing.
If I'm not wrong, there is a draft PR for that:
https://github.com/OSGeo/grass/pull/1212
Markus
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
