Early Access Programs

What is an EAP?

Early Access Programs (EAP) provide early versions of our software for developers to test with their applications and influence its new features prior to General availability (GA).

Why should I participate in the EAP?

The EAP is your opportunity to influence the future release. You can use the EAP to:

  • Ennsure your application upgrades to the latest release with minimal effort.
  • Verify new features can be used immediately in your application.

What is expected of me in an EAP?

The minimum expectations are that you:

  • Download the EAP packages.
  • Modify your code base if necessary per the Upgrade Guides and provide feedback if there are errors.
  • Verify your application compiles and provide feedback if it does not.
  • Perform basic testing of your application to ensure that it still runs as expected and provide feedback if it no longer works as it previously worked.

What we would like is:

  • Perform full QA testing of your application and provide feedback where the program no longer works as it did before.
  • Fully evaluate and provide feedback on any feature we have introduced.
  • Monitor and provide feedback on issues reported by other EAP participants.

How do I register for the EAP?

Click here: Early Access Program sign-on

What if I do not participate in the EAP?

The biggest risk is that something new breaks your code. This is not our intent, but it can happen.

During an EAP, we have options available to us to resolve conflicts:

If you only discover a conflict after the official release, you may have to wait until a maintenance release for the issue to be resolved, or we may decide that it is the future path for the product and that you have to amend your code if you wish to upgrade to this release.

In addition, when you go to use a new feature, you may find that you are restricted in its use because it is missing a feature that is important to you.

It is much more difficult for us to make changes after a release has occurred.  With a maintenance release:

  • We do not want to force users to edit 4gl code in order to install a maintenance release.
  • We do not want to force users to compile 4gl code as part of installing a maintenance release.
  • We do not want to force the concurrent installation of two or more of our products as part of a maintenance release.

The best time for us to make changes is in the EAP period prior to the GA release.

Think about this real-world example:

Consider Genero’s two base.StringTokenizer methods. Why two methods?

Feedback about ‘what happens if the delimiter is escaped’ or the ‘case of empty tokens’ was received after the base.StringTokenizer.create method was released.  We could not change this method to add two extra parameters; that would break anyone’s code that used it. We had to create a second method (base.StringTokenizer.createExt) to handle those cases, when perhaps the optimal solution would have been to have a single method.