Is there some mechanism by which user tailoring can discern between db2 versions? I have the situation with one of the snaps that the version generates different levels of details. I was wondering if there was a way to make the definitions react to a version. Shouldn't be a difficult thing to add to the product as it could be an attribute of a tag.
I have thought about this and I do have a ticket open internally, I will hopefully be moving all the tickets out to SourceForge soon.
The problems I see with making an individual definition file act differently depending on the database is as follows:
Filtering within the file will get messy as we progress with each change we make for a database version, also it will be required to specify a version on every tag that could change from version to version, as well as a default tag (or we use the lowest version) for when match exists for the active database version.
What I was thinking it would be better to place the filter within the menu system and have completely different table definition file for different database versions.
Let me know what you think, I still need to come up with a nice way to mark what version and fix pack range a particular menu entry will be visible ,
The way I see it you don't need to tag for every version, you only need to tag the range.
e.g. <menu name>.<start db2 version>.<end db2 version>
where the db2 version is the DB2 code release "SQL09050".
The end version is say unknown/null if there isn't a range dependency. Can't see this being too hard to implement.
Another solution is to provide a xml tag for release dependencies. Sort of an if statement that could be extended for other uses. This is probably harder to implement but provides more power. The other way is have a attribute tag. Again based on a range concept. <tag startversion=SQL09050 ...>
By the way you should provide as separation between tailor and base so inhouse tailoring is clearly identifed. Just need a separate directory for in-house tailoring and search it first before the base.
To be honest I can't see it being a big task on my first alternative. Does it matter that the same info is repeated. We aren't talking large volumes.
You could even extend it past db2 by providing adding database.