Separated xsd files by release versions

[Jacques Le Roux <ja...@les7arts.com>]

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

Re: Separated xsd files by release versions

[Jacques Le Roux <ja...@les7arts.com>]

From: "David E Jones" <jo...@hotwaxmedia.com>
> 
> To be honest my vote would be to not have ANY files on the server and  
> always use local references.

Yes this sounds reasonable enough
 
> 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? :(

I think that having one version by release on a server is also a solution, but using xsd local files sounds easier from our POV

Interesting side note, thanks

Jacques

> 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
>

Re: Separated xsd files by release versions

[David E Jones <jo...@hotwaxmedia.com>]

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