One of the characteristics of the final stage of packaging a new version for a VISTA application is that we must paradoxically freeze development without freezing development.
We must freeze development because the distribution sent to the world has to be a specific, tested version of the software. Getting to that point requires constraining development toward satisfying the results of testing, not introducing new disruption late in the packaging process, when there won't be sufficient time to test it. In this pro-testing era, most people get this issue pretty well.
Less well understood is that development can never stop. The code is never good enough. That's not a scope-creep programmer talking; that's just the honest truth. Our needs will always outrace our ability to meet them, so we must always be innovating. Any "agile" methodology that fails to recognize this - or even scoffs at it, creating a default condition of stasis rather than evolution - is not agile at all. Agility is in part about speed of production, about giving our software lifecycle a fighting chance to address our continuously changing needs by continuously working to meet them. This means we cannot afford to stop development, not even during testing, verification, or packaging up a release for distribution.
The resolution to this paradox is that we split our efforts into parallel paths. Whenever work on the current version or current patch reaches the crossover point where its innovation has to be bent toward satisfying testing and verification so it can be stabilized and distributed, a new version or patch must be started in parallel to carry the torch of agile innovation forward.
That's happening right now, as MSC Fileman 22.2 nears distribution. As I finish the code cleanup and begin packaging it, bending the work toward stabilization, the need for Fileman innovation is no less pressing, so we are simultaneously starting work on our first two patches.
The first patch, which under the new OSEHRA VISTA numberspacing will be known as DI*22.2*10001, resulted from the cleanup of the first lines of all Fileman's routines I wrote about previously. I replaced the dozen nonstandard formats for dates and times - half of which Fileman's own date/time validation tools could not understand - with a single standard format for dates and times, ISO 8601, the only right choice of standards here, since it's the dominant international standard and is used in the Internet for all modern systems. Ironically, Fileman does not yet support most of the ISO 8601 formats - particularly those containing times - so we need to upgrade Fileman's date/time tools to do so. The development work is being done by Murat Khemesh and the FLAP Jordan team in Amman.
The second patch, DI*22.2*10002, will include changes to Fileman subroutines identified by Afsin Ustundag in his analysis for OSEHRA's ongoing Code Alignment Phase One, in which he identified numerous subroutines across VISTA that include a mix of argumented and argumentless quits, suggesting confusion about how those subroutines are called (except for error processing, a given subroutine should only be called one way, and its quits have to match the way it is called). A few of the routines he identified were in Fileman, so we're cleaning those up to quit cleanly and consistently. The development work was done by George Timson.
I have little doubt that more MSC Fileman 22.2 patches will be launched during the next couple weeks. As they are, and as these two progress through the patch-development process, I'll write about them and their progress here, starting with upcoming posts about each of these first two patches.