Create new mailing list wine-isv?

[Tony Lambregts]

On 12/16/05, Alexandre Julliard <julliard at winehq.org> wrote:
> Tony Lambregts <tony.lambregts at 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