As part of the project to make upgrades easier in for distributed Gen applications, there are two ways that we could go:
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”.
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.
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.
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.
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.
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.