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.