xenserver/xenadmin

Distribute the program via. Chocolatey

LordMike opened this issue · 3 comments

LordMike commented

Distribute xencenter via. Chocolatey. This will allow myself and others to maintain installations of and updates to the program via that tool. The process is not overly complicated, as shown in my repo below.

It could be added as part of the release cycle (building the nupkg and uploading it using the cli).

I've gone ahead and added XenCenter to Chocolatey (currently under review - possibly not visible):
https://chocolatey.org/packages/xencenter

The build repo is here:
https://github.com/LordMike/xencenter-chocolatey

stephen-turner commented

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 commented

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 commented

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