On 12/16/05, Alexandre Julliard julliard@winehq.org wrote:
Tony Lambregts tony.lambregts@gmail.com writes:
Well that is a real sore spot with me. You know that I am a strong supporter of wine but it really concerns me that we have gone beta and not addressed preventing regessions from getting into our releases in any way. We currently have no freeze or notification of exactly when the next release is going to go out. Sure we had the one big code freeze just before 0.9 but then we went back to releasing without any notification. At his point even if our application maintainers test their app every day there is no way for them to prevent that regression going into the next release.
The idea is that people should test the releases. The point of the beta phase is to encourage end users to test, and for this to happen they need to be able to get binary packages, which is what the releases are about. This is why I'm making releases more frequently too, so that end users are able to test effectively without having to build from CVS.
The goal is not to prevent regressions between every minor point release, it's to make releases frequently enough that regressions can be found and fixed quickly, so that they don't creep into the next major release. Now, if you think that doesn't work I'm certainly open to doing things differently. What do you suggest?
Perhaps it's partly a matter of perception then.
If I understand you 0.9 was a major release then, and 0.9.1 and company are minor releases, with the next major release being 1.0. So I anticipate that we will have a major freeze before 1.0 just like we had before 0.9?
Since I'm pretty sure we do not have the resources to do nightly's like they did for Mozilla, then once certainly every two weeks is better than once a month.
If we could count on a release every two weeks that would be ideal. That way people like me who use CVS ( or GIT) could help prevent regressions even getting into the minor releases, which in turn would encourage more people to use the minor releases. I would prefer to see that releases were done on a Tuesday, myself, since I have more free time to track down regressions on a weekend and with some luck get them fixed on Monday. IMO doing this would be very beneficial to application maintainers without really changing very much what you are currently doing.
The next step up from this of course is to create a branch for bug fixes only but at this point I cannot say how beneficial that would really be.
One more thing. At the rate we are using up minor numbers we will be looking at at 1.0 being released sometime in March. This seems not to bad to me since having a major release twice a year seems pretty reasonable. Are we planning on doing release candidates for 1.0? Or are we just freezing the main branch. It seems to me that with GIT having release candidates is a lot easier then it would be with CVS.
--
Tony Lambregts