There are no release notes for this update on the support/download page for WWP 2003, and the release notes/readme that is supplied in the packaged update is for the wrong version (it's for 8.0.5, not for 8.6). Also, the download page is misleading. There is a "Compatible with FrameMaker 7.2 - Requires an updated license key" subtitle for the 2003 product downloads, but unless you've been following the update schedule closely, it's not clear if this applies to one or all updates.
Barton Wright has performed some testing on the update in a multi-version environment. His original message (27630) was posted to the WWP-Users Group. Rather than paraphrase Barton's words, I was granted his permission to reproduce his words here for those who are not members of the WWP-Users Group.
Barton Wright reports:
I got my new license key and installed the WWP 2003 8.6 "update" last night. I wish I could give a fully positive report, but I cannot.
The executive summary is:
-- Do not install this update unless you already have Frame 7.2 installed.
-- Do not install this update if you need to have more than one version of Frame installed.
-- Do not deploy this update in a production environment without careful testing.First, let me explain why I quoted the word update. All Quadralay needed to do was issue an 8.0.9 release on top of the most recent public release, 8.0.8. That is, they could have taken their code base from their source control system for the last public release of WWP 2003, added a few very minor Frame 7.2 compatibility fixes, and issued a simple update.
For whatever reason, Quadralay did not do this. Instead, they jumped ahead to a different development branch, the 8.6 branch. Now, Quadralay never released an 8.6 version of WWP 2003. We can only speculate that the decision has to do with the Automap product which did have versions 8.5 and 8.6 while the WWP 2003 product stayed at 8.0.8. For the next version of WWP, Quadralay decided to focus on the entirely new product, ePublisher Pro.
So when it came time to go back to the code for WWP 2003 to add Frame 7.2 compatibility, they made the odd decision to add those features to the unreleased, and (in my opinion) untested 8.6 development branch.
Thus, the 8.6 "update" is not an update in the usual software industry sense of the word. It is a different product under the hood.
Now, on its face, the 8.6 version looks and acts the same as the 8.0.8 WWP 2003 for the most part, so don't let me give you unnecessary worries. In limited testing so far, 8.6 has had no problem using a .WFP file from the 8.0.8 version and generating WebWorks Help from it. The generated help system does not look any different in limited testing.
But back to the differences under the hood:
-- The WWP executable in 8.0.8 is named wpubfm.exe. In 8.6, it is named wpublish.exe.
-- In 8.0.8, there are 22 DLLs in the bin directory. In 8.6, there are 40 DLLs, but not just a superset of 8.0.8. That is, 13 DLLs are identically named and are byte-for-byte identical between 8.0.8 and 8.6. The other DLLs are either newly added, newly named, or rebuilt.
-- Some DLLs that Quadralay gets from third parties have been updated to new versions. For example, the icu*22.dll files from IBM are now all icu*30.dll. The Xerces DLL has gone from version 2.1.0 to 2.5.0.Now these changes are not inherently bad, and they may turn out to be good, even very good. But anyone using WWP 2003 in a production environment dare not just plop down the 8.6 update and continue working. The changes are so extensive that careful testing is required.
Quadralay gave no notice of the extent of these changes. They just called it an "update." They don't seem to understand production environments.
Aside from the no-notice extensive changes, my complaints so far about the 8.6 update are the following. I will state in advance that they are all fairly minor, with no show stoppers. The problem with this list of complaints is that they are so basic, they give no confidence in the update. That is, if they can't get the simple things right, what else is wrong?
_______________________________
1. The change from version 8.0.x to 8.6.x explains why a new license key is necessary. Notice that your license key has the version number in it. Keys that begin with 2-000-021-80 must now begin with 2-000-021-86.
If Quadralay had issued an update on the 8.0.x branch, a new license key would not have been necessary.
_______________________________
2. The readme.txt file in the 8.6 WWP 2003 directory lists WWP fixed bugs through version 8.0.5. That's it, just through 8.0.5. No mention of the bugs fixed in 8.0.6, 8.0.7, and 8.0.8, all of which were listed in the readme.txt for version 8.0.8. That is, the 8.6 readme.txt file is a SUBSET of the 8.0.8 file, not the expected superset.
They just copied over the wrong version's readme.txt file, did not look inside it, and did not bother documenting any of the extensive changes or fixes between 8.0.8 and 8.6.
_______________________________
3. Most importantly, instead of adding Frame 7.2 to WWP's internal list of supported Frame versions, what this update does is tie WWP 2003 8.6 irrevocably to Frame 7.2. The 8.6 version presumes that Frame 7.2 is present and does not work without it.
This BREAKS a feature of prior versions of WWP 2003 that was present through 8.0.8, which was support for multiple installed versions of Frame. Please bear with me while I explain.
In the 8.0.8 WWP 2003, the Preferences dialog box has a checkbox at the bottom that reads "Reset/Update FrameMaker version and API".
When you check this box and click OK, a secondary dialog box pops up showing a list of the currently installed FrameMaker versions.
My laptop has three versions of Frame installed (6.0, 7.1, and 7.2) but still has the 8.0.8 version of WWP 2003. On that laptop, this secondary menu lists Frame 6.0 and 7.1, but fails to list Frame 7.2.
When I select a Frame version from the secondary menu, two things happen:
-- The WebWorks menu moves to the selected Frame version. That is, if I select Frame 6.0, the next time I open Frame 7.1, there is no WebWorks menu; when I open Frame 6.0, the Webworks menu item is present.
-- More importantly, your selection in this dialog tells WWP 2003 which version of Frame to open and use to generate MIF files. In 8.0.8, if WWP must regenerate MIF files, it opens the specified version of Frame even if another version of Frame is already open and running.*
(The dialog box selection of Frame version may perform other functions under the hood. The two items above are the visible results.)
This was a great feature of WWP 2003 for users who must keep more than one version of Frame installed (to support different clients or to support different doc sets from different eras). It allowed us to go back and forth between Frame versions with one license for WWP.
Now, guess what happens when you check the same "Reset/Update..."checkbox in the 8.6 version of WWP and click OK?
Ready? ABSOLUTELY NOTHING HAPPENS! No secondary dialog box pops up. There is no longer any way to specify which version of Frame to use to generate MIF files.
So what version of Frame does the 8.6 WWP open in order to generate its MIF files? Frame 7.2. Even if you have Frame 6.0 or 7.1 open, WWP 8.6 always opens Frame 7.2 if it needs to generate MIF files.
I don't know what happens if you install WWP 2003 8.6 on a system without Frame 7.2. I hope that would be an installation error caught by the WWP installer, but I have not tested that case.
_______________________________
4. The installer for the 8.6 version does something different than prior versions with the WebWorks menu that shows up in Frame. As described above, in prior versions, you could move the menu from one installed Frame version to another with the Preferences dialog box. By contrast, the 8.6 installer adds the line that generates the WebWorks menu to the maker.ini file of all currently installed versions of Frame.
Like my laptop, my main PC has three versions of Frame installed: 6.0, 7.1, and 7.2. The main PC is the one I upgraded to the 8.6 version of WWP 2003.
After installing 8.6 , all three of my Frame installations had a new line added to their maker.ini files. The new line was (correctly) different for the Frame 6 installation than for the two Frame 7.x installations. Bravo, they got this part right.
So, after the 8.6 installation, all three editions of Frame now have a WebWorks menu item. Sadly, this menu is seriously broken in all cases. Here are the problems:
4A. In the case of Frame 6.0 and 7.1, there were already lines in the maker.ini file that invoked the 8.0.8 version of the WebWorks menu. The 8.6 installer failed to detect these pre-existing lines and comment them out (and uninstalling WWP 8.0.8 did not remove them). As a result, when those versions of Frame were first opened, they showed an error dialog complaining they couldn't find the old DLL specified in the old line.
This is an amateurish error that was easily fixed by commenting out the old 8.0.8-specific lines myself, but I should not have had to do that.
4B. More directly, the newly added WebWorks menu FAILS TO WORK in all three versions of Frame. On the WebWorks menu is one entry, "Publisher 2003." When you invoke that menu item, it is supposed to open WWP 2003 from within Frame.
In all three of my Frame installations, after 8.6 is installed,invoking this menu item produces an error dialog that says "FrameMaker was unable to launch WebWorks Publisher 2003 for FrameMaker."
Now, I have not personally gotten much use from this menu item. It is a very minor convenience at best. Everyone knows how to launch WWP from the Windows start menu or desktop icon. It's not even a gee-whiz addition to the WWP product.
But can't they get their own convenience menu item right?
4C. But worse still, and why I am so upset with this update: DIDN'T THEY EVEN TEST IT? How could any developer fail to notice this error unless he just didn't even try to see if it worked?
4D. What is even more infuriating about the failure of the WebWorks menu item to work is that there is such a simple workaround. All I had to do was copy the file in the WebWorks bin directory named wpublish.exe to a new file using the old name, wpubfm.exe. Voila, now the menu item works in all three versions of Frame, because the menu item was still programmed to look for the old 8.0.8 name of the WWP executable instead of the new 8.6 name.**
_______________________________
You may wonder if I am complaining in the face of receiving a free update to a new, presumably better version of WebWorks. If the 8.6 version is better, I am all for it. But:
-- Give us notice that you have made vast changes.
-- Tell us why it's better. Document the changes.
-- Don't break existing functionality and call it an "update".This is a new version, plainly and simply, not an update.
_______________________________
If you have read this far, I hope you will be wary of the 8.6 update.
Those of you with WebWorks support contracts, PLEASE contact Quadralay and send them a copy of this note. Those of us without support contracts would have to pay US$300 to open a support incident just to report these amateurish errors in their own update.
I will continue to report in this forum as my testing of this update proceeds, especially as regards compatibility with 8.0.8 .WFP files and the output they generate.
_______________________
_______________________* There is one exception. It appears that if WWP 8.0.8 is set to use Frame 7.1, it WILL use an already-open Frame 7.2 instance to generate MIF files. However, if WWP 8.0.8 needs to open Frame 7.x (because no version of Frame is open, or only Frame 6.0 is open), then it will open Frame 7.1 instead of 7.2.
** On a disk formatted with NTFS, there is a better workaround than copying the wpublish.exe file to a new file named wpubfm.exe. This is to use the Cygwin "ln -s" command to create a symbolic link from wpublish.exe to wpubfm.exe. In this way, there is only one actual file present in the directory, but with two names. If this does not make any sense to you, you can safely ignore it.
0 comments:
Post a Comment