I think I see what you are trying to do.
This might be difficult - not necessarily impossible - due to some limitations of EA's data modeling approach.
First, EA does not provide any gateway into the data modeling process. It is a black box as far as code generation is concerned. There are a few options, those on the DDL dialog, that are essentially global. These are stored in the Windows registry, and therefore affect all DDL generation, across all DBMS products and EA projects. A few additional options are provided for (very) specific attributes of some DBMS products; (I think) these are stored as tagged values, and affect individual elements when DDL is generated for specific DBMS engines.
===
NOTE: One particularly annoying - and dangerous, particularly in your situation - global setting is the database (or schema) name. I don't mean the output file, but the database that will be named in a USE statement in the SQL. Changing this setting affects all data models in all EA projects, including those that have already been created. Running DDL generation on any past or subsequent model will use the most recent setting (from any DDL generation effort). I've mentioned this to Sparx, but don't know if they will change this behavior; I've not had feedback either way.
===
EA also allows you to generate DDL associated with a single table if you want. This will use a subset of the available options (those with relevance to table-oriented SQL). You'll get the necessary DROP and CREATE statements, as well as any triggers associated with the table. You do this by selecting the table on a data modeling diagram, then generating DDL as you would for the entire diagram. Note that EA generates table-specific DDL for only one table. If you select multiple tables on a diagram, EA will generate the DDL for the last one selected.
Beyond these few options, EA controls everything about DDL generation. You cannot modify the algorithm or template that EA uses. Nor can you have EA test any attributes (tagged values, etc.) you set, and generate optional DDL in response to the test results.
This could make it difficult for you to generate depending on your version attribute (or any other value you use).
But there might be hope...
What you can do is break up your model into 'chunks' that will be generated together. Remember that (with the exception of generating a single table) this is all or nothing. Everything on a diagram, perhaps in a package, that is part of a data model will have DDL generated. So you must have use some kind of package hierarchy to segregate data model components into coherent groups.
You can also use transformation scripts - look at MDA transforms in the EA help - to generate these models. This is not DDL generation, but the construction of one model based on another. A common use of this is to create a 'pure' model that is independent of any DBMS. This could be used as the pattern to generate equivalent implementations in several different DBMS models. You could even generate the 'pure' model (or the DBMS-specific ones) directly from a class model.
In your case you might create such a basic model for your first version, then define transformations for each new version. The new models would be placed in their own package (or package trees) to separate them from other versions. You could also do this by hand; there's no requirement to use transformation scripts. Once you do this you can generate DDL for each version by selecting the appropriate starting point in your package hierarchy.
That might not be exactly what you imagine now, and it is certainly not fully automatic, but it just might do what you need.
David
