[QGIS-Developer] Release Cycle update

[Greg Troxel]

Marco Bernasocchi <marco at qgis.org> writes:

I'm writing with my packager hat on (pkgsrc), mostly, although I'm also
a user.

> We think that adding release candidates would benefit the project a lot
> since we would not be shipping code that has not been tested at large and
> we would have a simple way to tell people that we're getting a new version
> ready and it is now time to test it heavily.

That's great.  The really hard part is getting people to test before a
release, and this will probably help.

> Release plan:
>
>    - .0 packages will be called “release candidate” allowing us to improve
>    expectation management and collect user feedback
>    - during the .0 release candidate period, the release is first branched
>    and master un-frozen to allow the next cycle development to start
>    - The splash screen will include “release candidate”
>    - .1 would be the first “proper” release

I don't think that naming plan is good, because it's contrary to what
everybody knows about release numbering.  3.20.0 is obviously a real
release to many, even if you say it isn't (and therefore it actually
isn't).

There's been a problem in the world of a proliferation of version
formats.  Long ago, GNU autotools had a great scheme where the release
leading up to 3.20 would be

3.19.80		alpha
3.19.81
3.19.90		beta
3.19.91

but it seems nobody uses this.  The great thing is that they sort
correctly.

The new scheme is to call

3.20a1
3.20a2
3.20b1
3.20b2
3.20b3
3.20rc1
3.20rc2

The advantage of using this is that it's really obvious (to those that
are used to release candidates in general) that rc1 is a release
candidate.  And, packaging systems have had to deal with this for
others, and using the exact same scheme means no special-case coding for
qgis.

When I can, I update pkgsrc locally to an rc (and don't publish it).
I'm doing this for two programs I'm an upstream maintainer of, and I
have often done it for postgis.  That means that I've tested the entire
source tarball to package path, and then run the package.  qgis is so
big, and I'm not as active, so I don't quite get to this.  But I think a
number of people will.

So really the only quibble I have is that if something is an RC, name it
with rcN, rather than declaring that qgis is going to use version
numbers to use what everybody else knows (without reading your
definition) mean something else.



As an aisde, a reason I would find this hard to deal with is that the
qgis data package format seems to change with every release and I've
seen the notion that e.g. if I'm working in 3.16.4 on something and I
open it with 3.20.0rc1 and change something trivial and save it, I won't
be able to open with 3.16.4.  I realize this would be hard but I would
like to see write support for the previous formats, with upgrade only
when requested.   I may be off base or out of date, in which case please
ignore me.   But I think it would be good to articulate and document how
to test new versions without messing up existing data.

Greg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20210303/9bfeae32/attachment.sig>