I was wondering about this:
A lot of companies have lots of code build in pré-OE11 and they all want to move to OE11.
And these componies have lots of customers running in pré-OE11.
When the developers move to OE 11 and modify code then they are not sure anymore that this code will still run under OE10 (or earlier), so what is the way to go here?
1. Maintain alle the code twice: once for pré-OE11 and once for OE11
2. Do not start developing in OE11 until all the customers are in OE11 (that could take a while)
So any advice or comments on how you guys handle this problem will be appreciated !!
Part of the problem can be reduced by using a build server (e.g. Jenkins using ANT and PCT) and introducing a process of continous integration and frequent compilation on all required version of OpenEdge - on a central place (with tools that cost no money, thanks for Gilles Querret).
That way you can verify quickly without added human work if code compiles still on OE10 or V9 or even on 11.2 - if you started using latest keywords like the BLOCK-LEVEL ON ERROR UNDO , THROW.
When compilation of a single code base is required, a developer can then add conditional compilation around critical statements in most cases (&IF PROVERSION BEGINS "10" &THEN ...).
Yesterday you posted the question about the resx files. We run a routine on our Jenkins/ANT/PCT environment twice a day that ensures that the resx files (those that are needed on V10) can be used on V10 by instantiating all serialized object in the resx file.
Those two techniques help us a lot.
However, you still need to actually test the application once in a while on every required version of Progress.
As stated by Mike, using conditional compilation will let you write your code for both versions, and if you have automated your builds, you'll be able to trigger them on any configuration you can afford (multiple OS, multiple Progress versions, and so on...) and know the outcome every time you commit new code.
One of the point PSC could address is the ability to know from Architect when a keyword has been introduced. As far as I know, there's no easy way to know this information directly from the editor.
Oh, that would be a nice enhancement!!!!
How would you like to see that in PDSOE (Architect)?
a) Configurable warnings in the problems view: ABL language versions
b) Tooltips when hovering over the keyword in source code (supported since version x.y)
a) Configure the project for a given version of Progress, and have the parser complain about missing keywords if a new keyword is being used. Or have the underlying AVM run this version instead of the PDS one, so that compilation will fail. This way we could always run the latest version of PDS, even when running older versions of Progress
b) Simpler (seen from my side :-) ), add this information in the online help and PDF documentation. This information should be available for every keyword, as well as startup parameters. I personally agree that if an option is there since v8 or before, it can be marked as there since forever !
And also +1 for the ideas of Mike
I'd say if it was there pre 9.1E we consider it as it had always been there.
but it can be a fairly complex thing. Its not just about keywords. Its also about the context.
Stop-After in 10.2B support constant time period only. In OE11 it supports variable ones.
NEWing an object requires parenthesis pre 11.2 before you can use methods of the new instance. Then Julian got that fixed.
so running the AVM of the desired target version to compile would certainly be the most complete, as suggested by Gilles.
how about supporting multiple parallel builders for different OE releases in PDSOE?
Some ABL keywords can be used as property names now, but couldn't pre 10.1C
The idea of having several versions of the compiler bundled in seems like a very easy one to accomplish and would provide a lot of potential.