I’m trying to backtrack why the current Windows releases are so different from 2.38 in order to be able to understand what to do to get them fully-featured again, which they are not.
Does anyone have info about Windows releases after 2.38?
Were there any? Where?
Why did the .msi installer disappear?
What was the state when Erwin Janssen started his work?
What was the state when he stopped?
Automated build existed for a while on Travis. Is it possible to access them?
Anything else?
This would have been a gold mine if it hadn’t stopped at 2.38.
None of us have much Windows experience.When AT&T was supporting the project, a developer was building the stable releases and packaging them manually. We were already having some problems with the installer occasionally wiping out someone’s PATH so I think we disabled that feature in the install maker. So around 2014 we lost all that. A while later, Erwin Janssen set up the CI build on Appveyor. There were a lot of messages on GitHub about this including using cmake for 64 bit builds.
I believe we just pointed to the Appveyor build and hoped for the best. I don’t think anyone sorted out any installer other than the zip file created on Appveyor.
Around this time we were all really distracted by major life issues and probably not responding enough or we considered the job basically done because the builds ran on Appveyor. Possibly this led to disappointment on the part of Erwin and Chiel etc. or maybe they just figured they had brought it as far as they needed to and stopped working on it. It’s history at this point.
One take-away is that it takes a lot of care+feeding to maintain an active open source project including builds and releases. I am not sure how to make that happen without it being anyone’s day job.
I’m trying to build up some chops as a cross-platform developer and that has made me focus on dependencies and packaging. I’ve had success using CMake to pull in source for library dependencies (ANN, Criterion) and build them as part of the overall Graphviz build process. This would ideally resolve the issues with 32- and 64-bit precompiled dependencies and eventually reduce our responsibility to maintain pre-compiled dependencies in a git subproject. The nice thing about the CMake approach is that it’s transport-neutral; source can be retrieved via git, URL, or unpacked from a local file (good for people working behind strict firewalls).
Ideally we could reduce the number of required dependencies but barring that, reducing the work needed to keep dependency builds current would free up more attention for bugfixes and enhancements. It also puts more control in the hands of user-developers so if a dependency breaks for them locally, they have a chance at fixing it and (ideally) passing the fix back upstream.