OldCroc wrote:
With all the problems that too many seasoned users, of SeaMonkey,are having, is it possible that the "Final" release of version 2.0 was released PREMATURELY?? Yes, there are many satisfied users, also, but there ARE too many who are NOT and the attitude of the developers should be to listen to the users, and try to rectify Version 2.0 OR WITHDRAW IT UNTIL IT REALLY IS READY!!! I have read where it is said that the old code was not usable anymore, or could Not be corrected, but it seems to me, that Version 2.0 IS NO BETTER! WHY DID THE DEVELOPERS COMPLETELY IGNORE WHAT THE USERS WERE SAYING ALL ALONG, AND THEN DEVELOP A LIMPING NOT-READY FOR PRIME TIME VERSION, ANYWAY?
In this regard I would have to agree in general with the assessment of Seamonkey developer Robert Kaiser who has responded to your comment in this thread. To be fair, overall, the code stability of the SM 2.0 application ITSELF is basically as good as, if not more stable than, all previous SM 1.X versions I have used in the last few years. It's true that the automated profile and user data files migration can be tricky, and the automatic migration utility have varying success with this depending on the user's system set up / configuration with past SM 1.X versions.
There are also a lot of different upgrade / migration methods that users of different experience ranges use which can also impact the success of the automatic migration. For myself, I have always performed migration for the Mozilla suite and Seamonkey releases manually. If the user has a thorough understanding of the key profile files and configuration files that needs to be migrated, the automatic migration process can actually be skipped / omitted completely for an even cleaner migration outcome, which is exactly how I migrated from SM 1.X to 2.X with great success.
I applaud the Seamonkey developers NOT to reinvent the wheel even though in SM 2.0 they moved to a completely different developer toolkit much more based on Mozilla Firefox and Thunderbird. But the great thing was that all the user data files, profile configuration files from SM 1.X were essentially by and large fully compatible with SM 2.0. The only real exception I've found so far is the browser history data file, where SM 2.0 used a completely different format. Even that was easy to migrate because I found out at some point that SM 2.0 will auto convert an old format browser history file to the new history data file format if one just simply planted the old browser history file in the SM 2.0 profile directory, and when SM 2.0 was started up, the application was smart enough to detect the presence of the old history data file and immediately convert it to the new format.
While I understand that not every user has in-depth knowledge of Mozilla suite and SM profile configuration files and a manual migration method is not always feasible for all users, my personal experience with manual migration was delightfully easy and smooth, and I did not need to end up with a second set of my e-mail data files had I used the automatic migration method. There are many subtle but important improvements in the SM 2.0 Messenger mail/news client, not the least of which is the way it has improved and more logical / sensible thread sorting logic compared to SM 1.X.
Before I performed SM 1.X to 2.0 migration, I performed a complete hard disc image back up so that I had the option to if necessary, completely restore my hard disc partitions to exactly the way they were before anything was changed, had I ended up with a botched migration. Then all that was necessary was to install SM 2.0 and create a new profile in a disc location that I preferred, delete the default profile, and then manually migrate all the SM 1.X key profile files into the SM 2.0 profile directory. I even decided to let SM 2.0 "suck-in" the parameters from the SM 1.X PREFS.JS file even though I was unsure of the final outcome but decided that it was a worthwhile risk to try, because I knew that PREFS.JS would be automatically rewritten by SM 2.0 upon quitting th application anyway, so any SM 1.X PREFS.JS parameters would either by recognized by SM 2.0 when it first read it, or just ignore old prefs parameters. But SM 2.0 sucked-in all the 1.X prefs parameters I had successfully and as a result, I did NOT even have to recreate / reconfigure all my multiple mail accounts, SM 2.0 immediately found them at their original locations. To recreate all my multiple mail account and newsgroup settings would have been a pain in the neck. It was pretty much a snap. There was some minor PREFS.JS editing I had to perform, because I decided to move my news folder location, but it was a simple search and replace operation using a text editor on the PREFS.JS file. So for power users who know the application intimately, this is one option to migrate. But I think that anyone who has that much familiarity with SM configuration files, will probably have figured that out themselves already.
Overall, SM 2.0 is very stable, there are some quirks that surfaced some of which had serious impact in the application's useability, but after some diagnosis it was determined that it was due to differences in 2.0 compared to 1.X and could be compensated in the meantime by reconfiguring preferences. Even with features that were in SM 1.X that are now absent from SM 2.0 for the meantime, it was due to switchover to the new development tool kit and I understand there are development efforts in the future to reverse this temporary feature regression that occured going from SM 1.X to 2.X. After all was said and done, I would stay with SM 2.X and look ahead to future minor update releases.
_______________________________________________ support-seamonkey mailing list support-seamonkey@lists.mozilla.org https://lists.mozilla.org/listinfo/support-seamonkey
