(In reply to Ralf Habacker from comment #0)
> This task is intended to track required task for the DBus 1.12 release on
> Windows.

Sorry, but I am not going to delay releasing 1.12.0 for Windows' benefit. On Windows, D-Bus is a supporting component used by relatively rare, Unix-centric third party software. On Unix (and particularly Linux), D-Bus is critical OS infrastructure.

Targeted bug fixes and whatever binary releases you want to do are welcome, but to minimize regressions, new feature work will have to wait for 1.13.x, just like the new feature work I started on Bug #100344. I'm planning a release of 1.12.x *because* it's a chance for production, OS-level, long-term-supported users of dbus to get all the stuff we already added in the 1.11.x cycle, without newer and less-tested changes destabilizing it for them.

> 1. Specify minimal supported os version and compiler

In practice, you are the only maintainer using Windows-native compilation or MSVC, so whatever you don't test isn't (actively) supported. What is the oldest branch of Windows you test on? What is the oldest MSVC you test?

The oldest gcc/mingw branch I'm interested in supporting is the one in Travis-CI's Ubuntu 14.04 environment (currently gcc 4.8.2) just because it's a convenient CI target, unless you have a reason to care about an older one (like perhaps an older one in OBS).

I would suggest borrowing the policy that I apply to Unix, and saying that anything that is no longer supported by its upstream vendor (hello Windows XP) is not interesting to us. If that cuts down the possibilities enough that you can support what's left, great. If that still leaves too many for you to support, drop the oldest/most-annoying versions until you reach something reasonable :-)

I had a look at adding CI via Appveyor, which seems to be a fairly popular Windows/MSVC equivalent of Travis-CI, to stop our ability to build on MSVC regressing without being noticed; but I don't really know how Appveyor works, so  I didn't get very far. I'll open a separate bug and attach what I had so far.

> 2. complete open bugs (for example bug 99751)

Sorry, I think that one is 1.13 material at this point.

> 2. Update website 

What needs updating, out of interest?

> 3. Make binary packages for Windows
...
> 4. Find a download location for binary packages e.g.
> https://dbus.freedesktop.org/releases/win or something else if not possible

If you are in the "dbus" Unix group, you can upload to dbus.freedesktop.org. If we release binaries, I would prefer them to appear in a new https://dbus.freedesktop.org/releases/dbus/windows-binaries/ or similar, so that they're next to the dbus source releases, which are in /releases/dbus/ - other subdirectories of /releases/ are used for parallel projects like dbus-python and dbus-glib, so it would seem less appropriate to go "one level up".

Are dbus Windows binaries of interest to end users, or are they only useful for bundling with larger projects on Windows like KDE or individual KDE apps? dbus doesn't do anything useful on its own (to be useful, something else needs to be using it to communicate) so user-facing installers don't necessarily seem particularly useful - it would seem a much better user experience if installing KDE or a KDE app brings in everything necessary for it to work. So perhaps it's only helpful to distribute source, or possibly binaries in a 7z/zip file that can be redistributed by other projects?

I have heard anecdotal evidence that MSVC-built libraries are only compatible with other libraries built with the same compiler in the same flavour (debug or release), and gcc-built binaries are less useful in the Visual Studio debugger than MSVC-built binaries. Is this still true? If so, I don't think it's realistic to try to distribute all the possibilities. Which one(s) did you have in mind?

There are several efforts that redistribute consistent prebuilt packages of open source software for Windows, analogous to the role of Linux and *BSD distributions - I'm aware of at least MSYS2, Microsoft's vcpkg, various projects in OBS, a reasonably large collection of cross-compiled libraries in Fedora, and a rather smaller collection of cross-compiled libraries (just enough to support Wine, NSIS and win32-launcher) in Debian. Would it perhaps work better (less work/better reward) to ensure dbus is kept up to date in one of those, rather than doing our own thing - analogous to how I maintain dbus in Debian, and I don't try to release distro-agnostic Linux binaries upstream?

> If this is not
> possible or will be too much work, or may be rejected by the obs maintainer

I am definitely not going to delay 1.12.0 while waiting for feature development in OBS.

Expanding on that a little:

As far as I'm concerned, our "product" as an upstream project is source code, and our main audience consists of the dbus maintainers in the various major Linux distributions (and other OS distributions that include dbus, and "ports" distributions like MSYS2, BSD ports and macOS Homebrew that act as addons to OSs that don't include dbus). We release source code that is believed to work in various environments; they do the necessary packaging and integration to get binaries for their particular environments. They are responsible for choosing which branch they track, and if a particular dbus release is not ready for a particular downstream software distribution (perhaps because it was released during their freeze process, or because there's a bad regression, or because we accidentally added a dependency that they don't have) then it's up to them to not pull in that release just yet, and talk to us about any bugs.

I would be hesitant to ship official binary releases as part of the upstream dbus project, because there already lots of downstream efforts that do that, and they are not going to use our binaries anyway: the point of an OS or "ports" distribution is that it applies consistent practices to all its packages, like building them all with compatible compilers and the same --prefix. So I'm concerned that "official" upstream binary releases would still just be one among many binary releases, and not necessarily even the best one.

In particular, I wouldn't want dbus.freedesktop.org to ship binaries for Expat and GLib[1] as our dependencies, because both have had security-sensitive bugs in the past, and I don't want the upstream dbus project to be responsible for updating those third-party binaries in a timely way. If we aren't going to re-host those, then we have to advise users to get them from "somewhere"; but then why don't we advise users to get dbus itself from that same somewhere?

If you are happy to maintain dbus binaries as part of (for example) windows:mingw:win32 on OBS, great - we can point to that as one of several potential sources of internally-consistent "stacks" alongside things like MSYS2, just like Debian and openSUSE provide internally-consistent sets of packages for Linux. If one particular stack is particularly well-maintained (obviously, yours is the best and the others are mere imitators, just like I could claim that Debian is the best Linux distribution :-), we could consider recommending that one over others (in particular, "if you are going to bundle dbus binaries with your Windows project, we suggest the version from..." would be a useful thing to be able to say). But I'd prefer that to be done by pointing to some external source of binaries that also contains a compatible Expat, rather than by downloading and re-hosting the binaries it produced as some sort of "official" upstream release. Does that make sense?

[1] I know we don't *need* GLib, but the ability to run tests is nice, and I'd tend to think more positively about the quality/QA of downstreams that run at least a subset of tests than about downstreams that never do

(In reply to Simon McVittie from comment #1)
> > 2. Update website 
> 
> What needs updating, out of interest?
I meant the windows part at dbus.freedesktop.org e.g. update the supported compiler and os and general text.

(In reply to Ralf Habacker from comment #3)
> (In reply to Simon McVittie from comment #1)
> > > 2. Update website 
> > 
> > What needs updating, out of interest?
> I meant the windows part at dbus.freedesktop.org e.g. update the supported
> compiler and os and general text.

Because the website update topic may be valid for 1.13 and all the other topics are rejected for 1.12 I'm going to change the version in the subject to 1.13

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/187.