Re: [pkg-wine-party] wine plan for stretch
On 20.12.2016 04:18, Michael Gilbert wrote:
> On Mon, Dec 19, 2016 at 10:58 AM, Jens Reyer wrote:
>> On 19.12.2016 03:44, Michael Gilbert wrote:
>>> Here is my plan for stretch. Wine 2.0 is coming soon, but not soon
>>> enough, so I don't plan to promote it to plain wine.
>>> So at stretch release, wine will be 1.8.something and wine-development
>>> will be 2.0.something.
>> I expect the timetable to be tight, but not a problem. What dates do you
>> have in mind?
> The anticipated dates don't really matter all that much. In addition
> to the at this time uncertain schedule, this is also about not having
> two source packages providing the exact same version in the exact same
> release. That is not useful to anyone.
> And no, removing wine-development from stretch is also not a solution either.
If src:wine-development is older than src:wine for a release, I'd
suggest to make it a transitional package depending on the latter. I can
I see src:wine as the default Wine. Both wine-development and backports
are great things, but I expect them only to be tried if the default Wine
Then there's great value in default Wine being from the latest stable
release series (2.0.x), because it increases the chances for running an
app successfully out of the box (apt install wine && wine setup.exe).
At the same time I assume the regressions from 1.8.6 to 2.0 will be
negligible. The release quality of Winehq even for the first release in
a new stable series (before any point release) imo is very good and
totally acceptable for a Debian release.
I think having the choice between two Wine flavors (src:wine as the
latest stable version, and src:wine-development as the latest
development version) is sufficient, and better then to ship each
supported version from Winehq, e.g. wine1.8, wine2.0 *and* wine2.1.
Users with an exotic problem which requires a specific version can use
debsnap or playonlinux.
> Unless there is an incredible significant reason otherwise, please do
> not upload 2.0 as src:wine prior to stretch.
Of course not, ACK.