啊，@winder你介意再问问Jfrog吗？

@J-Dunn，您可以在以下位置找到二进制文件：https ://github.com/winder/Universal-G-Code-Sender/releases/tag/v2.0.11

不好了。感谢提醒，再次联系 jfrog …

@J-Dunn，您可以在以下位置找到二进制文件：https ://github.com/winder/Universal-G-Code-Sender/releases/tag/v2.0.11

感谢那。为什么这不直接链接到 github 上？我点击了所有看起来合乎逻辑的东西，因为我认为这里有下载。jfrog 是收入来源吗？

长期以来，jfrog 一直是一项免费提供的便捷服务，因为 ugs 是一个开源项目。在过去的几周里，它变得不太方便了。

Thanks. Why not just use github like most projects seem to do ?
I went to look a jfrog and they seem to spend an enormous effort and meaningless blurb to avoid saying what they are actually about. If I had a project I wanted to distribute, I’d still be no wiser about what they offer. Very strange kind of presentation.

@J-Dunn jfrog is definitely an enterprise solution, in the artifact management space they are well known. For UGS, and the features we figured out how to use, it’s overkill. If I’m remembering right there were a few reasons I picked it:

1. the current github release storage didn’t exist when we were choosing where to put artifacts. There was a much older pre-microsoft release distribution system, but it had been specifically deprecated and removed.
2. back then I really wanted to have an auto-update feature in UGS, which needs more than a simple static binary storage. I tried using sourceforge, which kind of worked, but jfrog was way better.
3. back then UGS had a rolling release model, you basically had the “nightly build”, or something really old.

None of these are really true anymore.

1. microsoft seems to want github to be a one stop solution for the entire SDLC, so I would be surprised if this feature goes away.
2. auto-update isn’t really a priority anymore.
3. @breiler has completely revamped the release process, and now UGS fits the model supported by github.

Thanks for the detailed explanation.
If jfrog is broken , why not just drop it and rely on the archive you already have here which breiler link to?

@J-Dunn let’s let @breiler weigh in, but in the meantime… want to make a PR to update the links?

I don’t mind using github as the main release storage. Unfortunately the auto update service will not work, but that is maybe ok.

@winder if you want I can have a look at it?

Where is this autoupdate software? Is this something additional being installed along with UGS?

It is built in to the framework we are using available in the plugins menu:

However this requires that you configure an update URL and only work properly with the nightly build: https://groups.google.com/g/universal-gcode-sender/c/GRK8HXwucaA

It is better and more safe to update using versioned builds.

Thanks for the clear explanation.
Can I point out there are strong objections to having this kind of thing slipped into software and activated by default , which your link states as the ultimate objective here.
Basic system security means having control over what gets installed and KNOWING when that is happening.
Also maintaining a reliable system means sticking with what works until you have a reason to upgrade. UGS is far from finished to the point of not having things break on newer versions. That last thing I need is my CNC machine to go down because UGS updated behind my back and there’s a compatibility or other bug with the new version.

Bugs in machine control software can be costly and dangerous.

IMO this is a really BAD idea in this kind of application, even if some may think it’s “cool” to be able to do automatic updates.

In my personal experience software updates on all kinds of devices are frequently a cause of problems and need to be done at times when manpower, expertise and workload allow for ensuing issues to fixed without highly inconvenient and possibly costly down time.

My approach would be to completely drop this kind of feature. If it is retained, it must NOT be “on by default” and MUST be clearly flagged to the user in the top level presentation of what the software does.

My2c.

我已将所有下载链接替换为使用 github 而不是 jfrog。现在使用 github 操作完成每晚构建，这些操作将上传到 github 版本。不过，构建真正的版本还有一些工作要做。