January 12, 2005 at 3:56 pm #1424
MESI is proud to announce the release of Multi-Edit 9.10.04!
In this latest release, integration support has been added for Visual Studio.NET 2003, a Codewright command map, an updated version of Polystyle, much faster Perl RE searching, a number of long standing bugs have been fixed and much more! Please be sure to review the readme.txt file for a complete listing of all the new features and fixes.
Be sure to click on Help | Check for Upgrade and download your update today!
MESI StaffJanuary 12, 2005 at 4:39 pm #5090
MESI is proud to announce the release of Multi-Edit 9.10.04![/quote:rjc7c4ll]
Is this in any way different from the 9.10.04 beta release from early December? If it is, is there any way to force an update to happen (since the automatic upgrade didn’t fire)?
JohnJanuary 12, 2005 at 7:23 pm #5091
Yes, the release has quite a few improvements since the beta and RC1 releases.
The Help | Check for Upgrade in the beta will not locate the new download since it is using the same version number as the final release. Either use the Help | Check for Upgrade from a non beta copy of Multi-Edit or run the following command from the Multii-Edit main directory
[/code:2nhm3907]January 13, 2005 at 6:18 pm #5093
The Help | Check for Upgrade in the beta will not locate the new download since it is using the same version number as the final release. [/quote:287y27r3]
That’s why it isn’t a good idea to ship any code out of house which contains the next release version if it isn’t actually that version. It should be trivial to add logic such that:
[code:287y27r3]9.10.04RC1 < 9.10.04[/code:287y27r3]
i.e. anything trailing the version number makes it automatically less than one without the trailing code. You can get more sophisticated and teach it to recognize the difference between BETA, RC1, RC2, etc. This is a particular issue I have interest in, and I have actually added code to the Perl core to support structured version comparisons.
That’s tricky (lying to the system to force an upgrade)!
JohnJanuary 13, 2005 at 9:33 pm #5094
You can’t expect a beta version can be easily upgraded to the release. I use beta versions of different software and the requirement to fully uninstall beta before installing release is quite common. From this point of view upgrading MEW beta is quite friendly process.January 18, 2005 at 2:46 pm #5103
You can’t expect a beta version can be easily upgraded to the release.[/quote:1hd6kozb]
It wasn’t a Beta release, it was a Release Candidate. That is a subtle, but important distinction. Frequently, a RC is 100% the same as the final release (and in some projects, it must be, since the only thing that can be added to a RC is a severe bug, at which point a new RC is cut). This is why I originally asked if the RC was different from the release.
JohnJanuary 19, 2005 at 12:33 am #5104
It wasn’t a Beta release, it was a Release Candidate. That is a subtle, but important distinction. Frequently, a RC is 100% the same as the final release (and in some projects, it must be, since the only thing that can be added to a RC is a severe bug, at which point a new RC is cut).[/quote:12ptl1fh]
I’m sorry but according to my experiences, RC is usually just a next beta. The only difference is it should have complete feature set and it also isn’t always true. Especially when milestones are planned by marketing. The good example is XP SP2; the difference between RC2 and RTM was rather signifficant for me (as I had to rework my driver again ).
You wrote how it should be in the ideal case. And don’t forget we speak about installation which is usually the least interesting thing for developers. Automatic and supported update from RC could be of course possible but it would mean more work and maintenance. As beta testers we always have to accept possible problems and anyway, beta testing is voluntaryJanuary 28, 2005 at 6:11 pm #5133
Gotta back Michal on this one. I’ve never worked anywhere where it wasn’t clearly-understood although unstated that anything that wasn’t officially labeled “Release Version” or something similar was beta, or even alpha code (MS itself has released alphas–think they call them “technology demos” or “pre-Release Candidates” or some such–and installing them on a production machine was playing with fire; they now make explicit disclaimers on their “non-Release” code, likely to give the high-powered legal talent on retainer more time for golf–simulated, of course, since they acquired the major golf game some time back Got a friend who was working on that last time I looked).
There is a way to keep your settings and get the latest installed, though, and it’s what I usually do. First, rename your old installation directory something else, then create a new directory in the original location with the original name, and install to that from scratch. When you reach the point where it asks if you want to import a prior setup, just point it at the renamed old directory. About the only thing the current installer might not catch (depends on how you set up your session and project options and locations) is session and/or project files. If it misses them, either manually relocate them so they occupy the same place they used to, but relative to the new directory, or, if they’re not too involved, just recreate them from scratch.February 1, 2005 at 9:57 pm #5148
I’ve never worked anywhere where it wasn’t clearly-understood although unstated that anything that wasn’t officially labeled “Release Version” or something similar was beta, or even alpha code.[/quote:30ufwjxu]
Not to belabor this point, but I don’t have any problem recognizing that “RC” means different things to different people. Perhaps commercial projects (where the impulse is frequently ship it now and fix it later) work differently than open source projects. For the Subversion project, and indeed Perl itself, the final Release Candidate is indeed exactly the same thing as the released tarball, since there is only external testing available.
But my larger complaint is with releasing code in a public beta test which is indistinguishable from the full release based on the code’s own version testing subroutine. It is trivial to extend the package version such that each build has a different version, yet not burn “Release Version” numbers unwisely. It is even reasonable to mandate that the Beta and RC versions cannot be upgraded by the normal installer. What I think is less than helpful is to send out a Beta/RC which appears to be identical to the final release. I think you are shooting yourselves in the foot (in terms of support calls) by not making any public release (Beta or Final) immediately recognizable to the installer code.
You must be logged in to reply to this topic.