Simon Riggs wrote:
My thinking is to move to a two stage release process: Do one "production" release annually, and one "dev" release at the 6 month mid-point. That way each new release contains a manageable number of new features and we have a realistic chance of integrating them successfully. Support companies would then have the option to support both releases, or just the main production release. Leading edge users, of which we have many, would then benefit from more frequent additional features.
I like the idea of draining the patch queue mid-way through the release cycle. That'll hopefully encourage people to submit patches earlier in the release cycle, knowing they will be reviewed. It'll also give people working on external projects, drivers and tools, a checkpoint to sync with.
But I don't like the idea of making a release out of it. Who would use such a release? No one in production. Making a release comes with a cost, even if it's just a dev release.
One could also argue that we don't need the mid-cycle checkpoint, if we just keep the patch queue empty all the time. In the end, it comes down to how many people we have actively reviewing patches and giving feedback (I agree that it's not a linear relationship as you pointed out later in your mail, though). I believe a mid-cycle checkpoint would help by directing efforts to review, just like the pre-release feature freeze does.
I would also suggest that 8.3 be labelled a dev release. We have a reasonable number of fairly invasive patches, so we need a mechanism to integrate them with reduced risk.
I have no reason to believe that the next release will have less patches in it, so if we went down that path we could never release a stable release. If we have reasonable doubts about the stability of a patch, it should not be included. That said, all patches come with a risk.
With those two suggestions, the prod release would freeze on Sep 30 and the dev release on Mar 31. This would then put us into the same situation as Linux, where odd-numbered releases are dev and even-numbered are main releases. Everyone would understand our decision to take this action, as well as immediately understanding how this process will work in the future.
We're having a short 8.3 cycle because we wanted to shift our release schedule from Autumn to Spring. That would get us back to releasing in Autumn.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
