Gen EDGE

  • 1.  Choices for easier upgrade of distributed applications

    Posted Aug 27, 2015 03:06 PM

    As part of the project to make upgrades easier in for distributed Gen applications, there are two ways that we could go:

     

    • Leave the names and environment variables the same as they were for 8.5.

     

    This means that migrating from 8.5 to 8.6 for most distributed applications (GUI may be the exception which may require a relink in order to pick up a new stub) would be as simple as only deploying the 8.6 runtime; no other changes (including PATH changes) would be required.  The downside is that all files and environment variables that have version 8.5 information in them (such as the GEN85 environment variable or the WRF850N.DLL Windows runtime file or the VWRT85.JAR Java runtime jar) would all retain the “85” text in the names of the files (although the property information for each file would contain the real version information).  So even when we come out with release 8.9 or 9.x, the file names and environment variables would all still say “85”.

     

    • Rename all files and environment variables to be version neutral (i.e. GENxx environment variable becomes just GEN, the WRF850N.DLL Windows runtime file becomes WRFN.DLL and the VWRT85.JAR Java runtime jar becomes VWRT.JAR).

     

    This means that migrating from any earlier release (including 8.5) to 8.6 will require the usual regens, recompiles and/or relinks but upgrading anytime in the future will be as simple as only deploying the new runtime for that release.  The property information for each file would contain the real version information but the file names would not give any indication of the version.

     

    Please respond with any comments/suggestions you may have with these or if you have any ideas for something different.  Note that although our current preference would be the first item, our minds are not made up.



  • 2.  Re: Choices for easier upgrade of distributed applications

    Posted Aug 28, 2015 10:37 AM

    My vote would be to have no version identifier in the DLL/package names as this would be less confusing over the long term at the expense of a one-time change.



  • 3.  Re: Choices for easier upgrade of distributed applications

    Broadcom Employee
    Posted Aug 28, 2015 10:53 AM

    I agree with Darius.  In addition, it would be confusing to new customers in the future to be using release 8.9 or 9.x and having file names including 85.



  • 4.  Re: Choices for easier upgrade of distributed applications

    Posted Aug 30, 2015 05:58 PM

    I'd agree that pulling out the numbers would make more sense longer term.

     

    However, I think you should consider releasing PTFs for the currently supported versions of Gen (8.x) which transitions the existing installs to using the new system.  With the C target, you should be able to create symbolic links of the old names to the new ones, leaving existing applications intact (they'll chase the link) and it means as they regenerate/rebuild their load modules, they'll transition to the new ones.  Theoretically, by the time they jump to a newer release, the majority of their code base would already be transitioned to the new names.  Of course, that also depends on other things (like Visual Studio version compatibility etc.).

     

    Java/C# will be a problematic pain for this, I suspect - the C# DLLs don't look like they're versioned on number, but from reading the documentation, they'll be versioned on internal packages.  I suspect Java is similar, though the majority of the JARs look to have version numbers in them.

     

    Having said that, you could label it an optional PTF, with notes indicating that it'd require the regeneration/recompile of LMs going forward.  That way they can either choose to opt into the pain early, with the promise of no regeneration required at the next upgrade, or opt into the pain later, when they finally do upgrade.  It could help to mitigate the risk of an upgrade if they can do it in 2 phases and shake down their application before the upgrade itself.



  • 5.  Re: Choices for easier upgrade of distributed applications

    Posted Aug 31, 2015 03:58 AM

    My vote also goes to the no-version approach. This however means that CA must ensure backwards compatibility when releasing new versions. Otherwise we will be forced into critical upgrades like “Christmas day cutovers”. With the existing version approach we can have more versions running side-by-side.