search

ronivay / XenOrchestraInstallerUpdater

Xen Orchestra install/update script
GNU General Public License v3.0
1.16k stars 189 forks source link

Select XO release instead of just latest update #117

Closed APz closed 2 years ago

APz commented 2 years ago

Would it be possible to make the updater check what's the latest release version of XO and then update to that if it's newer than what's installed? Right now it seems to pull the very latest bleeding edge version there is, often having some work-in-progress or downright broken features that would get fixed by the time of the next release.

ronivay commented 2 years ago

Hi,

No. There's no releases for XO from sources installations. Yes there's versioning in xo-server and xo-web but those don't have any guarantees like one would expect from a release. Also tracking the specific commits that update those would be quite painful. If you need tested and stable release, you need offical XOA. The whole point of from sources installations is to track the bleeding edge latest master branch commit version. xo-install.sh has the rollback feature you can use in case latest version introduces issues and you need to go back.

APz commented 2 years ago

I'm actually surprised by this, I kind of expected them to tag the releases. For a homelab environment, I don't expect to have paid support from Vates, but running the same exact version of the software as official release would have been a nice bonus. Anyway, closing this.

ronivay commented 2 years ago

Yeah there used to be tagged releases for xo-server/xo-web but they stopped doing that in 2019. Actually script did have (and still has :D) a feature to use latest tagged release but that's obviously obsolete nowadays. I should probably remove it to avoid confusion.

olivierlambert commented 2 years ago

There's multiple reasons for that.

  1. XOA (Xen Orchestra virtual Appliance) is tested in a specific environment: the VM where it's delivered. There's no guarantee whatsoever from installing the same commit on a different system.
  2. XOA is meant to be sold as a package: service/support AND turnkey version with validated env
  3. Having people using the version from the sources on master is a way to contribute on the project itself: reporting the issue before it lands in XOA (at least in QA) is really helpful for us

That's why we decided to go this way. But we also made effort to work only on feature branches to limit potential bugs in master (it should work when it lands in master).

We are not the only project working like this (bleeding edge with all features vs pro support on tested/stable platform, eg VyOS is doing something very similar).

Also, since we release every month, the gap isn't that big, especially in a home lab context :)