Documentation Did not see 15.01.44 announcement

#5
As Vince wrote, nothing should be in the normal update location that is not meant for everyone. Any beta build, whether to test a fix for a single user's problem or a generic one, should be delivered in the beta directory. A strictly private build should not only not be delivered via the common update path, but it should not even share its version number format with the production versions; all communications relating should be private.

BTW, I now use both 32b and 64b versions on my one Win7 system, and the 32b version on my two XP systems. I report this only for future reference.
 

rconn

Administrator
Staff member
May 14, 2008
10,326
94
#6
As Vince wrote, nothing should be in the normal update location that is not meant for everyone. Any beta build, whether to test a fix for a single user's problem or a generic one, should be delivered in the beta directory. A strictly private build should not only not be delivered via the common update path, but it should not even share its version number format with the production versions; all communications relating should be private.

BTW, I now use both 32b and 64b versions on my one Win7 system, and the 32b version on my two XP systems. I report this only for future reference.
Build 44 was not a private version -- it was intended for everyone, but it wouldn't have been of any use to you personally, because the fix it included was only for build 43 users who had never installed a previous version.

In fact, build 44 would have made things worse for you because of Microsoft's change this week to block all XP access to the VS2012 redistributables. So you would have expended a large chunk of your limited bandwidth to download something of negative value -- and you're upset because I didn't encourage you to download it?
 

rconn

Administrator
Staff member
May 14, 2008
10,326
94
#7
Well, there's this built-in check_for_updates thingy. Don't you expect users, especially those who aren't regular visitors to the forums, to use it once in a while?
Yes, and if they did (and Steve never uses it) they would have seen in the update notes inside the updater that there wasn't anything in build 44 of any interest to them.
 
#8
Yes, and if they did (and Steve never uses it) they would have seen in the update notes inside the updater that there wasn't anything in build 44 of any interest to them.
Do you expect users to decide, based on the (often sketchy) update notes, whether or not to update? I'll bet that many (I for one) simply feel comfortable staying up-to-date.
 
#9
Rex:
I appreciate how you keep track of so many of your users' individual needs. However, like Vince, I normally download all builds, except when the logistics don't work out (I have not yet expanded the energy to automate it). Occasionally I have a chance to use an internet connection not my own; when that happens I grab everything I can and don't yet have. However, if there is an announcement describing limited or no benefit, I might not install everything.
Build 44 was not a private version -- it was intended for everyone, but it wouldn't have been of any use to you personally, because the fix it included was only for build 43 users who had never installed a previous version.
In fact, build 44 would have made things worse for you because of Microsoft's change this week to block all XP access to the VS2012 redistributables. So you would have expended a large chunk of your limited bandwidth to download something of negative value -- and you're upset because I didn't encourage you to download it?
No, almost exactly the opposite. What I suggested was that if a new build is supposed to fix a type of problem that might occur again in the future, but the fix is not yet proven, it should go out as a private or public beta, and only when validated (which did not happen in this instance) be moved into the "update" area. This procedure would have in this instance avoided some reported issues. We love your product, and even more your responsiveness to problems, but as individual human beings, sometimes we prefer modifications in the distribution methods; our preferences may not always fit your requirements. For example, if there were an issue with the upgrade procedure, you'd have to use the upgrade path to distribute a build which is essentially a beta version. In such event the .aiu file could contain a highlighted warning to install it only if specifically requested.
 

samintz

Scott Mintz
May 20, 2008
1,245
11
Solon, OH, USA
#10
I don't know about Steve or Vince, but I get a nearly infinite return on my investment in this product. Personally, I looked at what changed in this build and opted not to download it as the changes seemed mostly related to the installer and documentation.

I truly appreciate the care and quality you put into TakeCommand, Rex. It is an awesome product.