Distribute the program via. Chocolatey about xenadmin

[stephen-turner]

Thank you for your contribution, Mike. It's good to see XenCenter on Chocolatey. I'd be interested to know how easy the process was, and whether there are any assumptions in our software that made it difficult.

You suggest adding it to our release cycle. Of course, we already have release locations, namely xenserver.org for the open source version and citrix.com for the commercial version. So what I'm wondering is, are packages on Chocolatey typically maintained by the authors of the software, or are they maintained by third-party maintainers? If Chocolatey is "apt-get for Windows", one would expect the latter, in the same way that Debian packages are usually built by Debian maintainers from the upstream sources, rather than by the software authors.

[LordMike]

It's actually very easy, due to the fact that you've made a simple no-bullshit MSI package. They just install and uninstall without issues.

The release process really boils down to:

• Updating the .nuspec file. This file contains the version number and any relevant changelogs (the rest is static information)
• Updating the install script (the .ps1 file) with an updated URL and a SHA1/MD5 hash of the file in question.
• Pushing the packaged .nupkg to Chocolatey.

Anyone can push any package to Chocolatey, evident by me pushing your software. But it seems to be best if the software developer is the one pushing packages, as this opens up for a number of benefits:

• The software developer is implicitly aware of new versions, changes to install paths, new dependencies, quirks and bad versions that should be withdrawn
• The software developer can link back to their bug trackers and issue trackers on Chocolatey
• The software developer can assert their brand - currently I control the descriptions f.ex.

As for debian and others, I find a mix of the methods in real life. I've seen numerous software package sources, where the build scripts for various packaging systems is in the repository - meaning the developer maintains the packages.

[stephen-turner]

Citrix is not going to maintain such a package, though there's nothing to stop someone else doing it.