Feature requests

P.S. And just recalled one bug to report: wyUpdate ignores system proxy when working with FTP. Switched to HTTP(s) to overcome this.

Hey Andriy,

>> "1) Add support for semantic versioning according to http://semver.org/ (which, with upcoming NuGet support, going to be defacto new standard in .Net world). So far I have to reformat versions specifically for wyUpdate, and I can't mix prerelease and release in single project/channel."

I'm not quite sure what you're asking here. We support multiple version schemes in wyBuild: https://wyday.com/wybuild/help/versionnums.php

Or are you talking more about the ability to release updates to certain users?

>> "2) Add option to delay wyUpdate launch a bit, to let calling application shut down itself without giving user option to kill it straight away. Have no workaround for it, and couple users already managed to get crash message in our app this way. Not cool."

You can do this within your app (namely, launching wyUpdate closer to when your app is finished executing).

>> "3) Add optional command line parameter for specifying how long into past to build updates (ideally by specifying timespan or number or revisions... or even both). I have workaround for this, but it's reeeeeally ugly."

That sounds interesting. But I think our incremental update support (coming in the next version) will solve this problem.

>> "4) Provide API for generation of client.wyc, ideally MSBuild task (even more ideally distributed via NuGet). I have created one (just to patch version) myself and it works perfectly... At least until next release of wyUpdate."

This already exists: https://wyday.com/wybuild/help/commandline.php

>> "5) Embed theme information into project file in some way so it's not dependent on current user. Completely embedded will be fine with me, but it's up to you. Just don't force me to google once again where is Local System's %AppData%"

This is being fixed in the next version.

>> "6) Take control over this: https://www.nuget.org/packages/AutomaticUpdater/. It's fine the way it is, but I'd prefer it to see uploader being Wyatt. I believe current uploader won't mind neither."

I'll look into that.

>> "7) Not bothering me much, and probably way more complex to implement: maintain own cache of release files, can be as well affected by retention policy from 3a)"

We're thinking about ways to handle this. No solution yet.

>> "Also, since you mentioned that wyBuild isn't commercially profitable... You saved me lot of trouble. Won't speak for all users, but I don't mind paying for new version. Even popular now subscription-like approach will do."

We're leaning towards a subscription model (and grandfathering in existing accounts that have purchased within a certain timeframe).

Hello Wyatt.

Thank you for response. Let me clear up on some bullets:

1) Basically, I'm talking about extending what is considered valid version number according to aforementioned specification and also resolving version precedence respectively. E.g. 1.0.0-alpha.5 is considered valid version according to SemVer 2.0.0, which is lesser that 1.0.0-beta.2, which in turn lesser that 1.0.0-beta.10 and this one is lesser that 1.0.0. Also version can contain suffix that starts with + which is completely ignored on precedence comparison.

2) Yes, in case I'm controlling execution of wyBuild manually. With AutoUpdater control, it's not that trivial.

4) I spend a bit of time thinking about how to word this one properly, but it seems I still need to add more (lot) of context. I know about wyBuild command line, but generation of client.wyc (or at least update of version number/target location) IMHO shouldn't be something tied tightly to wyBuild project. Here is scenario: I can build installer (which includes client.wyc) for every source control revision. But not every revision going to be published. So it doesn't make any sense to create records for versions in project just to create client file. But still I wan't my installers to update properly, even if particular version wasn't published (e.g. I don't wan't my installer for app of version 20 to have outdated client.wyc of version 5, and then update to last published version 15. On the other hand if there is version 22, I'd want them to upgrade. I'm fine with fallback download for this case - normally it's not production stuff anyway). My solution is that I just have client.wyc from some ancient version under source control and just patch it for every installer built with custom MsBuild step. wyUpdate handles all the rest perfectly. Also this simplifies my publishing process generally: instead of building app part of solution - running generation of client.wyc - building installer part of solution - publishing with wyBuild I just have: build solution (both app and installer), publish it. Same can be said about embedded location of wyserver.wys file, but this is easier, since can be overridden in code.

I'd even consider splitting project in half, since that two entities are really independent: client part actually belongs to wyUpdate, it defines how it looks, what version we currently have and where to check for updates (tabs General Information, Theme, Languages, Download Sites and Build wyUpdate). It doesn't have to know about what versions are published, and totally can be placed under source control. Also generation of proper client.wyc must be part of automated build process, since it is one of client binaries.

On the other hand server part, it's only about versions: tabs Update Information, Files & Folders, Registry Changes, Update Actions, Build Updates and Upload the Updates. It's sole purpose is to tell whoever asks about what versions are at stock, and what's in them. Also it has to maintain memory of what was already published, so it can't be under source control, since every release will alter its state. Now that I think of it, I more and more come to conclusion that it shouldn't be part of any project at all, but rather previously generated updates should be treated as this server part of the project. Especially taken into account that it has all the information needed. E.g. I'm publishing version to new server location. wys is created, all.to.version is created as well. Consequent publishings will have all files needed to do comparison and generate deltas (so it is solution to #7 too). And this will allow publishing on different channels easily, e.g. create update location per feature branch.

Well, that's enough of philosophy (I wasn't asked for) for one post 🙂 Hope some of my ideas prove useful.