Ask Reuben

Maintenance Release 01

Why do i need to update all Genero products with this release?

If the version number is XX.Yy.ZZ, what does it mean if y changes?

Why is this release 4.01.00 and not 4.00.04?

The title for this week’s article is a play on words on the use of 101 for a course in the basic knowledge of a topic, and the fact that last week saw a Maintenance Release that had 01 as the second component of the version number i.e. 4.01.00 rather than incrementing the third number.

In the release announcement, there was an important note in red and capitals…

UPGRADING TO GENERO BDL 4.01 REQUIRES AN UPDATE OF ALL GENERO PRODUCTS TO VERSION 4.01.

You will  have observed that the second digit of the second component of the version number changed. That is instead of this being an upgrade from 4.00.03 to 4.00.04, this was an upgrade from 4.00.03 to 4.01.00

This type of maintenance release we managed to avoid with the 3.x release, there was no 3.01, 3.11, 3.21, but was something that happened with the 1.x and 2.x releases. If you look through the historical list of upgrades you will see there was a 2.51, 2.41, 2.32, 2.21, 2.11 etc and so what is occurring with the 4.01 release is similar to what occurred when 2.41, 2.32 etc were released.


Background – Version Number

Currently our version number is made up of three components X.YY.ZZ.  For this article I will split Y into Yy, so the version number is X.Yy.ZZ.

Ideally a maintenance release involves ZZ incrementing and X.Yy staying the same.  That is 4.00.03->4.00.04.  As a general rule of thumb 1 where two sub-products that make up the Genero architecture have X.Yy the same, this signifies that they can communicate with each other.2

A 4.00.02 FGL can be used with a 4.00.03 GAS and a 4.00.01 GRE and a 4.00.00 GDC because X.Yy is the same.

Also code compiled using 4.00.02  fglcomp and fglform can be run with 4.00.01 version of fglrun because X.Yy is the same.

Whenever something in this communication protocol between our products change, this will require a change in X.Yy.

Ideally we bundle lots of these changes together and this is what makes up our major and minor releases where X.Y changes.  These are coincident with Early Access Programs and as there are multiple enhancements and issues resolved, a good testing period is suggested.

Occasionally with a maintenance release we need to make small change(s) in the protocol to fix an issue(s) or add an enhancement(s) that can’t wait for the next major on minor release, and this is where y changes, as has occurred with the 4.01 release.

1It is a general, not an absolute rule. There are times we have made products compatible with older releases i.e. the 3.2 GDC would run with any 3.X FGL

2Four Js License Manager which has a version beginning with 6 is an exception to this.  Hopefully by the time FGL gets upto version 6, FLM is still on 6 and we can bring them back in sync.  You may have observed GBC version jumping from 1.00 to 4.00 to get them in sync and simplify matters.


User Interface Protocol

The Dynamic User Interface and the Abstract User Interface Tree are the cornerstones of the communication between the back end and front end processes. For these two processes to communicate with each other there needs to be agreements as to the Nodes and Attributes of the AUI Tree and how the changes are communicated between each other.

So for example, if we were to add a new widget or new widget attributes both the back end and the front end need to be in agreement as to the name of this widget and attributes and the potential values of the attributes. fglform needs to know about these new values, fglrun might need to know about them as well, the front-end i.e GBC/UR needs to know what to do with these new values,  and historically the native GDC/GMI/GMA needed to know about the new values as well.

This is why new widgets, new attribute are typically added in a major or minor release rather than a maintenance release.  Take for example in 2.00 when we added SLIDER, SPINEDIT, TIMEEDIT.  There is no way we could have added these in a typical FGL maintenance release because this would imply you would also need to use a new version of the GDC that knows about these new widgets.

If there is a change to the User Interface protocols required as part of a maintenance release,  then the y in X.Yy will be incremented so that we can enforce that the front-end and back-end products are upgraded in sync.

This principal applies to the communication between other Four Js products.


P-Code Instructions

When a 4gl is compiled by fglcomp, it produces p-code modules (.42m). These modules are independent of the platform and contain a set of instructions that are interpreted by the Genero runtime fglrun.

For code compiled by fglcomp and executed by fglrun there needs to be agreement as to the meaning of the instructions within a .42m file.  If a new instruction is added or perhaps changes are made to an existing instruction then you enter into the realm of p-code incompatibility.  If there is a new/changed instruction,  fglcomp could place it in the resulting .42m, and hence fglrun needs to know what this new/changed instruction is supposed to do.

Normally with a maintenance release these instructions are stable, hence you do not need to recompile and deploy compiled objects with a new version of fglrun.  A slightly older fglrun (e.g. 4.00.02) will still run compiled objects compiled with a slightly newer fglcomp (e.g. 4.00.03) and vice versa

Ideally these instructions only change during a major or minor release when we add new syntax.

However in a maintenance release an issue  might require a new or changed instruction and this is where you see the y part of X.Yy.ZZ changing and a requirement to recompile your sources with the new fglcomp and co-ordinating the deployment of your compiled objects in conjunction with the new fglrun.


Summary

When you see a maintenance release that increments the y in X.Yy.ZZ this tells you there is a little bit more work and thought required compared to a maintenance release that simply increments ZZ.

With a maintenance release that only increments ZZ, you can typically just deploy an individual Genero product in isolation.  You do not need to recompile, and nor do you have to co-ordinate deployment of our products and your compiled objects.  We can say there is an issue in fglrun, deploy this version where this issue is resolved in the fglrun.  We can say there is an issue in the front-end client, deploy to this version of the front-end client where this issue is resolved.

When the y in X.Yy.ZZ has incremented, as is the case with the recent 4.01 release, this tells you you will need a recompile and you will have to co-ordinate deployment of our products and your compiled objects.  What level of testing you perform at this stage is upto you but it typically does not need to be at the level reserved for a release where X.Y changes.