[This message was posted by Toby Corballis of Rapid Addition <[email protected]> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/c56e36b1 - PLEASE DO NOT REPLY BY MAIL.]
At the risk of being contentious (who me?), I am interested in soliciting people's thoughts on FIX version lifecycles. It seems at the moment that there is no set policy on when a version becomes officially deprecated (if I have got that wrong somone step in quick and correct me). The concepts of lifecycle management in software (SDLC) and information (ILM), and in other Information Technology areas are not only well established but also accepted as best practice. It seems to me that without such policies for FIX versions the ultimate result is spaghetti; with many pasta chefs and waiters required to continually espouse the virtues of one sauce over another, when, in fact, the incremental benefits of the newer versions of mamma's secret recipe get overlooked. Most of the new generation of FIX Engines interpet the FIX version they process by directly loading from a schema-defined repository and, to that extent, can handle any version from 4.0 to 5.0SP2 (i.e. any version that is able to be data-model driven). So, the technology can cope. Another benefit I see is that intelletual resource can be better concentrated on how to move the protocol forward (that is not a sleight at any current committee or individual, rather a belief that fragmentation of intellectual resources is les valuable than concentration). [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]]
-- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
