Multi-Edit 9.10.04 Released!

Home Forums General Announcements Multi-Edit 9.10.04 Released!

This topic contains 8 replies, has 21,579 voices, and was last updated by  John Peacock 14 years, 6 months ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #1424

    Anonymous

    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 Staff

    #5090

    John Peacock
    Participant

    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)?

    John

    #5091

    DanHughes
    Participant

    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]
    MeUpg.exe /V=9.10.03
    [/code:2nhm3907]

    #5093

    John Peacock
    Participant

    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.

    [code:287y27r3]
    MeUpg.exe /V=9.10.03
    [/code:287y27r3][/quote:287y27r3]

    That’s tricky (lying to the system to force an upgrade)!

    John

    #5094

    Michal Vodicka
    Participant

    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.

    #5103

    John Peacock
    Participant

    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.

    John

    #5104

    Michal Vodicka
    Participant

    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 :-x).

    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 voluntary ;-)

    #5133

    ReidSweatman
    Participant

    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.

    #5148

    John Peacock
    Participant

    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.

    John

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.