Will wyBuild still be improved?

Yes, wyBuild is still being improved. We're trying to get the next version out in about a month (2.6.20).

So why the holdup? We did significant work integrating installer functionality into wyBuild and then a couple of factors forced us to ditch that work and try again.

The next major feature coming out in v2.6.20 is incremental patches.

Will it also include the ability to create the .wyp file from scratch, in a source control friendly way (xml/text)?

Wyatt,

Thanks for all your work with this product. It has been extremely useful to me.

Regarding the incremental updates: Will it be possible to switch an existing update deployment over to the new incremental system, without redeploying?

Will it be possible to switch an existing update deployment over to the new incremental system, without redeploying?

Yes.

I currently run version 2.6.18.4. Purchased last year. I am looking for a version v2.6.20 that is mentioned in this post.https://wyday.com/forum/t/1869/will-wybuild-still-be-improved/#post-9734

I desperately need the ability to create wyp files on the fly. It appears this product is no longer being developed. Is this the case? Do I need to find a new product?

It appears this product is no longer being developed. Is this the case? Do I need to find a new product?

An updated version is coming this year.

Wyatt wrote:> An updated version is coming this year.

That's what you said two years ago.

There are many things I would like to see in a new version. For instance:

Make a server component to be able to identify which clients have downloaded which update. And how many had installed the latest version in a period of time.

On the client side I would like to see things like detect if a file that doesn't need to be updated has been modified from its original version and make a full update instead of applying a patch.

That's what you said two years ago.

The schedules changed for many reasons. Mostly because we took a wrong turn in development that had to be reversed and done over in a much different way. It's been talked about elsewhere in this forum. Long story short: schedules change for many reasons.

Make a server component to be able to identify which clients have downloaded which update. And how many had installed the latest version in a period of time.

This is being included in LimeLM in the next 6 or 7 months.

On the client side I would like to see things like detect if a file that doesn't need to be updated has been modified from its original version and make a full update instead of applying a patch.

This already happens if the customer messes with files that need to be updated. That's what the catch-all update is for.

Presumably you want it for cases where a customer wants to mess with files that you won't be updating (in which case the catch-all update won't be installed). So, my question is: why would you want that? Presumably the customer will screw around with the files again once the update is installed. So, at best it's a fruitless operation.

Other improvements I would like to see in a new version are:

* Ability to erase no longer needed files (included in a previous version but not in the current one)* Ability to edit configuration files instead of replacing it* Integration with an automated build processes for creating a deploying updates automatically

* Ability to erase no longer needed files (included in a previous version but not in the current one)

We'll think about that. I'm not sure that's the best way to handle things. Don't you want to keep copies of your old versions so you can reproduce bugs?

* Ability to edit configuration files instead of replacing it

The way to do this is to generate and maintain configuration files from within your application. There's no good way to "merge" changes between a "default" file and the customer's changes. The "merge" algorithm is whatever you want it to be. So, if there are new defaults then save them to the config file along with whatever custom values the customer has put in.

That's a long way of saying we're not adding this because it's the wrong way to handle this type of situation.

* Integration with an automated build processes for creating a deploying updates automatically

You can already do that: http://wyday.com/wybuild/help/commandline.php

We'll think about that. I'm not sure that's the best way to handle things. Don't you want to keep copies of your old versions so you can reproduce bugs?

I think than that isn't either the best way to keep old versions. The best way would be to keep the original installer and all the updates and wyserver.wyz version in a test environment so you can update to any version you want. But my client should have a clean installation of the latest version, Sometimes old files can cause trouble or only waste space.

That's a long way of saying we're not adding this because it's the wrong way to handle this type of situation.

I think that a simple config transformation (at least for .net applications) would be a great additon and could help developers to avoid a lot of code checking for every parameter if its included or not and make assumptions of defaults values.

You can already do that: http://wyday.com/wybuild/help/commandline.php.

I didn't know about that, I'll give it a try, but what I can see now is that is not so easy to automatically generate a new xml file for each automatic build.

I imagine an scenario like this one:-I have a static xml file where I have a predefined directory for each Wybuild Directory, and optionally some aditional files, and a expresion to generate the new version number- Someone checks in code into the Source Countrol which triggers an automatic build and deploy- New files are copied to the folders on the xml file- wybuild.cmd.exe is called using the static, predefined xml- - An autonumeric new version is generated- - Files are moved to a new backup folder using the new version number- - Updates are builded and uploaded for this version

How do I enable the BBCode in this Forum?

How do I enable the BBCode in this Forum?

You can't, it's been disabled for all but admins. Reason: crappy spam filtering.

I think that a simple config transformation (at least for .net applications) would be a great additon and could help developers to avoid a lot of code checking for every parameter if its included or not and make assumptions of defaults values.

There's no way to do this. Config files can come in any form, whether binary or text, and in any format. There's absolutely no way wyUpdate would "know how to" merge config files. Hence, handling it within your app.

I imagine an scenario like this one:-I have a static xml file where I have a predefined directory for each Wybuild Directory, and optionally some aditional files, and a expresion to generate the new version number- Someone checks in code into the Source Countrol which triggers an automatic build and deploy- New files are copied to the folders on the xml file- wybuild.cmd.exe is called using the static, predefined xml- - An autonumeric new version is generated- - Files are moved to a new backup folder using the new version number- - Updates are builded and uploaded for this version

You can already do this, however the steps that wyBuild doesn't aleady handle are outside the scope of what wyBuild will handle. So, it won't generate a new version number for you. Why? Because you have that information. It can't guess what you want. It also won't move files around on your hard disk. Why? Again, because you have that information. And file-copy operations are simple in every programming language. So, put the files where you want them, then tell wyBuild about them.

An updated version is coming this year.

Any news about the release date of a new version of wyBuild, wyUpdate and the AutomaticApdater?We are all waiting for good news

It's being worked on. Our current goal is early 2016.

It's being worked on. Our current goal is early 2016.

Ok, I'll wait for that.Meanwhile, from where can be downloaded the source code of the version currently released?

Click the "Downloads" link at the top of the page and you'll find wyUpdate and the AutomaticUpdater with links to the source code repositories where you'll find the latest public changes (we have more current private changes, but they'll be released when we release the next version).

"There's no way to do this. Config files can come in any form, whether binary or text, and in any format. There's absolutely no way wyUpdate would "know how to" merge config files. Hence, handling it within your app."

That's why I'd said that only for .NET apps. app.config or web.config files are simple to edit and merge.

Since this question has been asked many many times, we've finally written a FAQ for it. FAQ: What's the best way to update config files?

There's no way (short of turning wyUpdate into an artificial intelligence that can intuit the customer's needs) that wyUpdate can "merge" config files. Hence handling inside your app.

"There's no way (short of turning wyUpdate into an artificial intelligence that can intuit the customer's needs) that wyUpdate can "merge" config files. Hence handling inside your app."

It's obvious that there is no way to solve all scenarios, but at least you can try to bring support to the most popular ones. There are many update solutions that allows to update xml files like "[X]"

I have suggested several improvements for your solution and you have discarded all of them (I had seen many of them working really well in other products). It seems that you are really mind closed or that you are not really going to update your product. You have been saying that you will for the last three years and never do; you always keep moving the release date but to date, AFAIK, there is no official release date or a list of new features

The only suggestion you had (that wasn't already a feature of wyBuild) was the config files. And we've told you why we can't and won't do it.

Re: the new version -- it's being worked on. We've announced a handful of features that will be available.

But like you said there are competitors out there that offer different features and we welcome you to try as many competitors until you find the product that meets your needs.

"The only suggestion you had (that wasn't already a feature of wyBuild) was the config files. And we've told you why we can't and won't do it."

I have suggested the following features (in different post on the same thread):

* Make a server component to be able to identify which clients have downloaded which update. And how many had installed the latest version in a period of time (you said that probably will be included in the next version)* Ability to erase no longer needed files (you said no)* Ability to edit configuration files at least for xml files or .NET config files (you said no)* Improve the Integration with an automated build processes to make it simpler and avoid the need to alter the config files for each release (what's the point of an automated process if you had to do a manual step every time) (you said that you already had one process and won't change it)

"But like you said there are competitors out there that offer different features and we welcome you to try as many competitors until you find the product that meets your needs"

Unfortunately I already bought wyBuild before trying other options, and I like that it very easy to use but it's very limited

* Make a server component to be able to identify which clients have downloaded which update. And how many had installed the latest version in a period of time (you said that probably will be included in the next version)

Trial tracking & specific feature usage tracking is being included in LimeLM. If you just want a broad-strokes tracking the tools are already there (logging, passing product keys to your servers alongside the check for update, etc.).

* Ability to erase no longer needed files (you said no)

That's correct. wyBuild actually needs the files to generate patches. It can't "remember" what to do to make a patch (that's why it needs an actual file on the disk). And very large hard disks are dirt cheap.

* Ability to edit configuration files at least for xml files or .NET config files (you said no)

If it was possible to do in a universal way, we'd jump on it. But it's not possible short of programming an AI into wyUpdate. Even then it wouldn't be accurate. Hence, FAQ: What's the best way to update config files?

* Improve the Integration with an automated build processes to make it simpler and avoid the need to alter the config files for each release (what's the point of an automated process if you had to do a manual step every time) (you said that you already had one process and won't change it)

wyBuild build automation is merely a step in the build process. It's not the entire process. You need to use something (like a script) to generate the XML file that will be used for the update so wyBuild actually does what you want it to do.

Unfortunately wyBuild can't just guess what you want and do it. People still have to tell it what to do. And in the build automation that "telling" is generating an XML file for it to use.

The year is running out pretty quick. Still waiting for an update. Im gonna be forced to change products If we dont get a way to build the wyp file from the command line.

PLEASE stop teasing us with words of an update and just give us one.

It's coming at the beginning of 2016 -- we decided to delay it months ago so we could release a large update for LimeLM. The wyBuild update coming in 2016 is a larger update that will reach a larger audience. This is important because it will: (a) make us more money and this means we'll (b) be able to consistently put more development time towards wyBuild.

A product re-focus like this (reaching a larger audience) is not a quick fix -- hence the delays. Once the "refocus" is done, we'll be able to consistently provide timely updates.

If wyBuild doesn't work for you in the meantime there are dozens of competitors out there.

Looking forward to the new LimeLM + WyUpdate.

I saw the download links earlier in this thread, particualrly "svn checkout http://wyupdate.googlecode.com/svn/trunk/"

Got anything on Github or similar?

Good luck with the new release. 🙂

Yeah, we plan on moving all of our open source code to an open Git platform (probably github).

>> "Good luck with the new release. 🙂"

Thanks. 🙂