Hi
It would be great if one can choose to use the bleeding edge versions. it can be quite messy to keep things up to date with dev versions on all various nodes one might have. I have like 8 nodes and I would hate to keep needing to upgrade to the dev versions manually. Maybe there can be an option that lets the user choose “use the nightly” or something like that so we can properly test on various nodes.
That’s deadly, as it’s usually broken or incompatible with something. Furthermore, it’s released usually once a week, therefore it’s not such a big wait.
However, you can specify the URL to upgrade to -upgrade-to, which can be for example:
http://build.syncthing.net/job/syncthing/lastSuccessfulBuild/artifact/syncthing-linux-amd64-v0.11.13+1-gbc0ce7b.tar.gz
and you can get the g<hash> part from looking at the commit hash of master branch.
Nothing that 10 lines of bash or powershell can’t solve.
Same goes for any feature branches, which I guess was your original intent rather than master.
Well that is the issue. I do not want to keep chasing versions and hashes etc on my all devices. Most of them are remote devices or mobile devices. I am perfectly fine with testing dev versions to provide feedback but I do not want waste most of my time on trying catch up with the dev versions and installing them on various devices regularly.
The dev versions might have a slightly tinted page so the users know that they are using the dev version if there is an automated way. Obviously the dev version is not the default upghrade option.
All it takes, is working out the URL once on a single machine, and then invoking a single command once on each machine…just like it would take to click a button to perform an upgrade on each machine, as given it’s a dev version it would not auto-upgrade.
If you don’t want to chase dev versions in general then don’t.
Essentially I see it like QA, and QA have to follow whatever procedures QA needs to follow to get the build running (which usually involves running installers etc) to get the QA done. It’s already pretty automatable compared to what standard QA for general products has to go through, hence I think bleeding QA logic into the end product makes no sense.
It also seems that there are many different modifications and improvements going on at the same time. That makes the “nightly build” difficult to choose… Which one of the many would you like to test?
I (personally) see it like this: We are still before v1.0 and therefore all the releases with v.0.x.y are beta anyway. The devs do everything to only ship out perfectly well versions, but everything can happen. If there are major changes, then die “pre” builds are available. And I am not sure any more, but i thought once you change to the “pre” tree, these pre builds upgrade themselves automatically. (But only for a specific v.0.x version)
(I just looked, but i can’t find any reference if Syncthing is still beta.)