On 3 Jan 2006 at 10:47, Mariposa Symphony Orchestra wrote: > Really pretty lame on their part - why NOT > call it 2006C and (more important) send out an e-mail to Win users? > Or at least (in keeping with their apparent fondness for the absurd) > "2006-b.2"!
Well, from the point of view of someone who writes software for a living, the reasoning is perfectly clear: 1. in general, you don't increment your major subversion except for a major update. Thus, it would make no sense whatsoever to call this 2006c, since that would falsely imply that the update was one with significant features in it. 2. there is nothing at all absurd about 2006b2 as a release number. Microsoft uses subversions and build numbers, such as Microsoft Windows 2000 5.00.2195. That means that it's the 5.00 release of Windows, but build number 2195. For my own programs I use version and build, e.g., 1.0115. That means that the software is the 115th build of version 1. "Build" indicates that it's the 115th compiled version of the code. My projects are much simpler than Finale, so I can have a single build number for my apps. But I also sometimes release version 1.0115a, 1.0115b, 1.0115c, and each of these are releases that fix one bug in release 1.0115. What this system means is that any two versions with the same build number are identical in functionality, though later instances of that build number have bug fixes that the original lacks. This is important when I'm having to recommend upgrades to users -- I need to know which variation of build 115 is in use to know whether or not an upgrade will help them. But from the end user point of view, all variations on build 115 are identical. In this case, this was just a single-file bug fix for 2006b, so it makes perfect sense that it not be given a new version number (i.e., 2006c). Secondly, since the fix was Windows-only, if it had been named 2006c, then the latest updates for Mac and Windows would end up with different numbers, which would be a nightmare for end users as well as for Finale tech support. If you think that's silly, just let me tall you about how many times my clients have asked me why they aren't upgrading to the latest version of MS Offices, such as Office 98 (which was the *Mac* version between Office 97 and Office 2000). Now, I'm not sure what MakeMusic could do to make this seem more logical to an end user not accustomed to the vagaries of software development. From a software developer's point of view, the two updates are identical except that one of the support files has a bug fix. From an end user's point of view, they are identical except that the later one has a bug fix. Clearly, to me, the later update should completely supersede the original one, and thus it makes complete sense to me to re-use the same release number (though somewhere there has to be a build number that tracks the difference between the original release of 2006b and the fixed release). For people who haven't yet downloaded 2006b, there would be no utility in distinguishing the fix from the original. Now, it's clear to me that the user interface for the update feature ought to handle this. If they are going to keep the same version number, then they have to have some mechanism of informing the end user that there's a change to the update that's already been installed. It sounds to me as though one is directed to a web page to download the update, and the web page has the explanation. But I believe it would be better if explanatory text, build numbers and release dates were included in the update notification (along with your currently installed build and release date) to make it clear. But I really don't think the problem is with the release numbers at all, which seem to me to be used completely properly, but with a UI that doesn't make it clear exactly what you're being urged to download. -- David W. Fenton http://dfenton.com David Fenton Associates http://dfenton.com/DFA/ _______________________________________________ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
