Hi, Another related point, I would like to make a minor change to our version numbering practice: keep the final .z in x.y.z even if it's 0. Then all our version numbers would follow the same pattern.
This change would make cases like the 1.2.1 release (where we dropped the 1.2 release candidate due to an issue and created 1.2.1 instead as the first 1.2.x release) more natural, i.e. the "1.5 release" would refer to the first release from the 1.5 branch, be it 1.5.0, 1.5.1, or even 1.5.12 (if we're hopelessly lost with release management :-). Also, I plan to drop the practice of calling preview builds as release candidates (as in -rc1, -rc2, etc.). The "release candidate" is the final build that is being voted for release. Once a release passes, the release candidate becomes the official release. The preview builds will instead be labeled with -b1, -b2, etc. These preview builds are not official releases and should not be published outside [EMAIL PROTECTED] The purpose of these builds is to enable pre-release testing and review already before all the issues targeted for a release have been resolved. PS. Perhaps we should instead treat the preview builds as official "beta releases", which would make it easier to distribute them to a wider audience for increased feedback. However, I'm not sure if that's worth the trouble of running official release votes. BR, Jukka Zitting
