When choosing a target version of PowerBuilder to migrate to, one needs to consider objectives.
10.5 Consideration: Note that while a major version upgrade involves a change in the first numeric element of the PowerBuilder version number, a move from any 10.x version prior to 10.5 up to 10.5 or later should be considered a major version upgrade. This upgrade will involve a one-way migrations and will make your PBLs incompatible with versions previous to 10.5.
Major Version Considerations
Most people are aware of the consideration of new product features as a factor in an upgrade decision. In fact, most upgrade decisions are based on new product features. Sybase literature and web resources should probably be considered the first stop in identifying new features of potential interest. The next stop could very well be our own list of historical changes to PowerBuilder and the announced future features of PowerBuilder.
Committing to a new or pending feature can justifiably cause some concern. The 1.0 Factor is a concern that a new product or feature may have been released with inadequate testing or implementation, which will only be fixed by the first patch or major release. (A variation is described below.) One way to alleviate this concern is to actively participate in PowerBuilder beta programs, announced on the Sybase web site. If a good implementation of this feature is of value to you, it may be worth the investment of time. Sybase typically responds well to good feedback (including providing reproducible cases, timely response to case interaction and discussion that doesn’t resemble hysterical or belligerent screaming).
Supported DBMS Interfaces
Typical PowerBuilder applications are interfaces to databases. Making sure that your choice of target version of PowerBuilder supports your DBMS interface of choice. Major versions upgrades both add and remove DBMS interfaces. Minor version upgrades historically just add interfaces.
If your DBMS interface has been deprecated, you might want to consider why this has occurred. If a database product has been end-of-lifed, supporting an interface to such a database may not be practical for Sybase, or any development tool vendor. The same applies to database interface standards. When Microsoft SQL Server 2000 deprecated the DBLib interface, keeping it available but unsupported, this essentially spelled the end of the PowerBuilder DBLib interface (also known as the MSS interface), since any issues Sybase may have needed fixed to support changes or improvements wouldn’t be done by Microsoft.
If your DBMS interface has been deprecated, you may want to consider your alternatives. PowerBuilder provides several interfaces to database interface standards, like ODBC and OLE-DB. If you can get a quality driver for your DBMS that supports one of these standards, that may provide a solution for you. Also keep in mind vendor changes. To follow up the Microsoft example above, Microsoft declared the new “standard” or “native” interface for SQL Server 2000 to be OLE-DB. In this case, a move from PowerBuilder’s MSS driver to the OLE-DB driver should provide more features and better performance. A last solution for connectivity may be to use an interface to an older version (e.g. an Oracle 8 interface to Oracle 10). Typically, this works, but won’t support new features.
Supported Operating System
This can be an important factor, depending on your user base. When Sybase announces that it no longer supports an older operating system, it is safest to assume that applications built with that version of PowerBuilder will not work on that operating system. Operating systems have been removed in recent releases of PowerBuilder, partly as a consequence of Microsoft removing support for those operating systems, and partly because of requirements to support new features (like Unicode).
Support of newer operating systems prior to announcement by Sybase is largely dependent on Microsoft’s success in providing forward compatibility for applications. For historical reasons that date back to the Powersoft days, there is always a time lag between the release of an operating system and support by PowerBuilder. This is because Microsoft retains and exercises the right to change anything between beta versions of the operating system and the released version. Because of this, no serious compatibility work can commence until the official release.
Support From Sybase
This is a critical factor in upgrade decisions for some companies. When Sybase no longer supports a version of PowerBuilder, this means that if you find a bug in PowerBuilder, Sybase will not fix it in that version, even if it is critical for you and there is no work around. If you are developing or maintaining a critical application, and find yourself in this situation, you may be forced into upgrades in a time frame that is not ideal for your company, very likely delaying a release of your application.
Historically, identifying the duration of support has followed this equation:
The targeted release cycle for PowerBuilder has historically been 12-18 months. Plug this into the above equation, and a PowerBuilder release is historically supported 2-3 years after its release. Put another way, Sybase usually supports a current and a previous version of PowerBuilder. These support duration guidelines are a statement of historical observation, and do not reflect a statement of Sybase policy. Sybase has recently implemented an effort to provide customers with one year notification of end of support. While the timing of the implementation of this policy extended the support life of PowerBuilder 8, such an extension is not expected to reoccur, and the announcement is going to be another step in the existing life cycle.
So, to maximize your time on a supported version of PowerBuilder, you want to adopt a version of PowerBuilder as early in the product’s life cycle as possible. Adopting a version late in the support cycle will mean that you will lose support more quickly without another migration project.
Maintenance Version Considerations
Given software development theory, it is impossible to rid software of significant size of bugs without virtually immeasurable resources (read: cost). Given that fact, once a choice is made of a major version of PowerBuilder to migrate to, choice of a minor version of PowerBuilder can be just as important.
Software development theory says that any given work on any given piece of code has a probability of creating a new bug. Given a development team working for months on a maintenance release of PowerBuilder, it is statistically impossible for the release not to have new bugs introduced. However, given an assumption that the number of bugs introduced is less than the number of bugs fixed, by blind statistical prediction, the best maintenance release you could possibly pick is the most recent.
However, statistical probability is not any guarantee. A full regression test should be considered an essential step in your migration.
Through observation, software users have come up with the theory that version 1.0 of any software tends to have a lot of bugs. A similar theory has been applied to version 1.0 of a new software feature, typically implemented in a version x.0 of an application. The theory suggests the benefits in waiting for the first patch before adopting software.
While early versions of PowerBuilder have supported this theory very well, long time users should be aware of the facts that initial releases since v8 have shown significant improvement over previous initial releases.
The way to combat the x.0 factor is to actively participate in betas, providing feedback to Sybase that is both useful and constructive. In the extreme case, should your application exercise PowerBuilder in a unique way that otherwise goes untested, a bug may slip past Sybase and the beta community that will go unfixed until you report it. Such bugs tend to have a better chance of getting addressed in a timely fashion during a beta cycle than during a maintenance cycle.
Upgraders often go to the user community to ask for the “most stable” maintenance release of PowerBuilder. The term “stable” implies an unbiased overview of the entire product. However, given the size and scope of PowerBuilder, it is unlikely that any single user will be able to provide such an overview. They can only provide feedback on the portions of PowerBuilder they use, and often generalize this experience to an alleged overview. Similarly, the upgrader probably doesn’t need an overview, but information as to whether the portions of PowerBuilder they exercise have any bugs that are likely to affect them. To hyperbolize, if PowerBuilder had all but one bug eliminated, in a feature that only 1% of the user community utilized, and I’m in that one percent and I get hit over and over by this bug, I’d probably call this a “very unstable” release.
While the desire to get a label like this is understandable, the accuracy of such a label from the user community needs to be considered suspect, and can never be a substitute for a serious regression test.