versioning

[Alucard]

this problem has been bugging me for some time. Hope I could find some help
in here.

I am designing a class library for reading and creating files of a certain
format, say for example, Formatted Text Document (FTD).


The names of the classes I have in mind to create are:
namespace FTD{
public class Document ...
public class Paragraph ..
public class Picture ....
}

Let's say there are two versions of FTD out there: 1.0 and 2.0

2.0 has some additional features that 1.0 doesn't have.

So therefore version 2.0 of the 'Document' class will have properties that
version 1.0 of 'Document' doesn't have.

So should I make the 'Document' class an abstract one and create the
subclasses 'Document1_0' and 'Document2_0'?
However, this polymorphism approach makes code maintenance difficult and
introduces complexity as newer versions of FTD become available.

Another approach is to expose the different versions through interfaces. For
example, make 'Document' implement IDocument1_0 and IDocument2_0, and
'Paragraph' implement 'IParagraph1_0' and 'IParagraph2_0' and the same to
all other objects. One main disadvantage is that this introduces code
complexity also.

Yet another method is to create different versions of the library, such as
FTD1_0.dll and FTD2_0.dll. But for this method, consumers of the library
have to check the file version and then load the correct library to read the
file. Also, code for common features between the two versions have to be
reproduced for the two dlls.


Lastly, I also require the design of the library to be backwards and forward
compatible, that is, the 'Document' class able to read files of an older
version and save it either in the latest or in the current version.

 

[Nicholas Paldino [.NET/C# MVP]]

Alucard (I just downloaded and finished SOTN for PS3, btw),

If you have a need for forward and backward compatability, then I would
have one Document class which exposes all the properties, and then for the
properties that do not exist for a particular version (and you should expose
that version through a Version property, or something of that nature) you
return a default, or empty value.

 

[DougM]

this problem has been bugging me for some time. Hope I could find some help
in here.

I am designing a class library for reading and creating files of a certain
format, say for example, Formatted Text Document (FTD).

The names of the classes I have in mind to create are:
namespace FTD{
public class Document ...
public class Paragraph ..
public class Picture ....

}

Let's say there are two versions of FTD out there: 1.0 and 2.0

2.0 has some additional features that 1.0 doesn't have.

So therefore version 2.0 of the 'Document' class will have properties that
version 1.0 of 'Document' doesn't have.

So should I make the 'Document' class an abstract one and create the
subclasses 'Document1_0' and 'Document2_0'?
However, this polymorphism approach makes code maintenance difficult and
introduces complexity as newer versions of FTD become available.

Another approach is to expose the different versions through interfaces. For
example, make 'Document' implement IDocument1_0 and IDocument2_0, and
'Paragraph' implement 'IParagraph1_0' and 'IParagraph2_0' and the same to
all other objects. One main disadvantage is that this introduces code
complexity also.

Yet another method is to create different versions of the library, such as
FTD1_0.dll and FTD2_0.dll. But for this method, consumers of the library
have to check the file version and then load the correct library to read the
file. Also, code for common features between the two versions have to be
reproduced for the two dlls.

Lastly, I also require the design of the library to be backwards and forward
compatible, that is, the 'Document' class able to read files of an older
version and save it either in the latest or in the current version.

Use strong naming and you can version the end users app with a config
file.