To be honest my vote would be to not have ANY files on the server and
always use local references.
The only real alternative would be to tightly control all changes to
these files and require new versions of them to be published with
version numbers in the file names, and keep ALL old ones around (in
other words, we wouldn't allow them to change very often).
We could have a separate site folder for release 4.0, but have those
ones even stayed the same since the release? :(
In other words, until we have official version controlled specs that
we stick to, we're going to run into this to one extent or another.
On a side note: this is one of the reasons I'm pushing for big
cleanups in the framework right now, and for people to get new
features that they want in right away. I'd like to separate the
framework from the rest of the project and include only a binary build
of it, and not the source. That means that we'd have things like (for
example, ie not real numbers) the applications version 5.0 using
framework version 1.5, until the official release of framework version
1.6 is done, and the applications 5.0 branch (or the trunk) officially
updates from 1.5 to 1.6, just like we would for any other library.
That means less agility, but a lot more control and stability for the
framework and the rest of the project as well.
What would hopefully happen is that it allows the applications (and
special purpose apps) to advance more quickly as efforts in them can
focus on the business side of things without the distraction of "I
wish the framework were this way or that way". Those thoughts could be
expressed through work on the framework.
-David
On Jun 21, 2008, at 1:38 PM, Jacques Le Roux wrote:
Hi,
We should kept separated xsd files by release versions and use them
in relative xml files.
For instance my XML editor is reporting an error in "<if-empty
field-name..." when working in release4.0 (this has recently
changed to field)
Jacques
