Marco Bernasocchi <ma...@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
signature.asc
Description: PGP signature
_______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer