Wine Stable/Release Changes

Michael Stefaniuc mstefani at redhat.com
Tue Sep 22 06:39:58 CDT 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

at WineConf we had a fairly uncontroversial discussion about the Wine
Stable release process. As the current process of feature based Wine
releases isn't working(*) following changes were agreed upon.

Release Process Changes
- -----------------------
- - Switch to time based releases.

- - Major releases once a year in autumn/fall. Code freeze starts around
  mid/end of September.

- - Michael Stefaniuc will be the stable maintainer starting with 1.8.x.
  Other people are more than welcome to help out with Wine Stable.
  I'll document stuff and send out a request for help during the code
  freeze.

- - The stable release will be supported in bugzilla.

- - This changes take effect immediately. You can expect Alexandre to
  announce a code freeze in the next couple of weeks.

- - We will revisit this changes should the need arise, e.g. reduce the
  time between two major stable releases.



Discussion
- ----------
The discussion was done based on slide 9 of Alexandre's keynote
http://wiki.winehq.org/WineConf2015?action=AttachFile&do=get&target=wineconf-2015.pdf
At the start Alexandre and others noted that we do not hear from users
for whom 1.6 is just working. We are getting reports only about the
stuff that breaks.
The discussion quickly geared to the changes accepted from above with
the focus on implementation details:
- - 6 months better? No, the 12-18 months stable release cadence prior to
  1.8 was ok. Can be reduced later on should the need arise.
- - Synchronize with (a) major distro? No, release dates can slip on both
  ends. Freeze should also not impact GSoC.
- - Nobody else volunteered during the discussion for the stable
  maintainer role.

For the more drastic proposal of removing the the Wine Stable version
altogether, Alexandre made drafted a plan to follow a similar model to
the Linux Kernel. One release for the risky stuff and every second
release is for stabilization. He proposed also a two weeks "merge
window" for risky stuff followed by two weeks for the fixes and the last
two weeks of "freeze". This produced a loud outcry from most developers:
it would be unworkable without a prior move to a git pull model to
accept new features. This basically killed the proposal.



(*) 1.6 released > 2 years ago and was latest updated 1.5 years ago. It
    doesn't compiles on a modern distribution anymore.


bye
	michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iD8DBQFWAT4O0ei8kcpE1VERAprfAKC0x+Zb6zHGv095REWGGYy+L/qsBQCgpr1+
Z9VxsMM7J1/wdpAyC8DPJaE=
=zhZ8
-----END PGP SIGNATURE-----



More information about the wine-devel mailing list