[QGIS-Developer] Release Cycle update

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[QGIS-Developer] Release Cycle update

Marco Bernasocchi-2
Dear developers,

following up on the 3.18.0 release issue discussion [1] and my proposal there [2], at yesterday's PSC meeting we prepared an updated release and communication plan.

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.

QGIS has clearly grown a lot in the years and has become indispensable for many users this is why we think we should do everything in our power to deliver the best possible product.
With the addition of the release candidates in our regular release plan, we want to take a further step in this direction and underpin the great testing efforts driven by the community.

Unless strong objections are risen here, the new release plan beginning with 3.20 will look like this:

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

Communication schedule:
  • .0 release → social media posts
  • .0 packages ready → “release candidate” blog post including visual changelog and call for testing and social media posts
  • .1 packages ready → “release” blog post and social media posts

Example with 3.20
2021-05-14
  • release of 3.16.7 (LTR)
  • release of 3.18.3
  • feature freeze in master
2021-06-18
  • release of 3.16.8 (LTR)
  • no 3.18.4 release
  • release of 3.20.0 Release candidate -> Release candidate communication
  • feature Unfreeze in master
2021-07-16
  • possibility to release a second release candidate
2021-07-16
  • release of 3.16.9 (LTR)
  • release of 3.20.1 -> Release communication
I'd like to take the opportunity to thanks everyone that gave feedback in the above-mentioned threads thus allowing us to come up quickly with the new schedule.

Cheers
Marco


_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Reply | Threaded
Open this post in threaded view
|

Re: Release Cycle update

Greg Troxel-2

Marco Bernasocchi <[hidden email]> 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

_______________________________________________
QGIS-Developer mailing list
[hidden email]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

signature.asc (199 bytes) Download Attachment