WCF DataContract Versioning - wcf

Question

Alright here goes nothing. After reading Best Practices on Service Versioning and Data Contract Versioning (http://msdn.microsoft.com/en-us/library/ms733832.aspx) I mostly understand how its all done. I am planning to use Agile Versioning for Data Contracts but cant figure out what the difference or better practice is between Creating a WorkRequestV2 to add new properties or just adding the new properties to WorkRequestV1. Now I tried doing both ways and it worked but when I do create WorkRequestV2 I have to modify ServiceContractor to use WorkRequestV2 why do this rather than just adding properties to WorkRequestV1? What is the difference?
The Example I looked at was here (http://msdn.microsoft.com/en-us/library/ms731138.aspx)
CarV1 and CarV2 why not add HorsePower to CarV1 and not have to create a whole new Contract.
[DataContract(Name = "WorkRequest")]
public class WorkRequestV1 : IExtensibleDataObject {
[DataMember(Name = "workrequest",Order=1,IsRequired=true)]
public int workrequest { get; set; }
[DataMember(Name = "CQ")]
public string CrewHeadquarter { get; set; }
[DataMember(Name = "JobCode")]
public string JobCode { get; set; }
[DataMember(Name = "JobType")]
public string JobType { get; set; }
[DataMember(Name = "Latitude")]
public string Latitude { get; set; }
[DataMember(Name = "Longitute")]
public string Longitute { get; set; }
private ExtensionDataObject theData;
public ExtensionDataObject ExtensionData {
get {
return theData;
}
set {
theData = value;
}
}
}

Answer 1

Have another read of the Data Contract versioning (your second link)
Here is a quote from that page:
Breaking vs. Nonbreaking Changes
Changes to a data contract can be
breaking or nonbreaking. When a data contract is changed in a
nonbreaking way, an application using the older version of the
contract can communicate with an application using the newer version,
and an application using the newer version of the contract can
communicate with an application using the older version. On the other
hand, a breaking change prevents communication in one or both
directions.
For your case, adding some additional properties is a non-breaking change. You can quite safely add the properties to the existing data contract rather than create a new one, as long as you don't have strict schema validation (such as the new properties don't have 'required' marked on them)
Old clients communicating with new services still continue to work, values of the new properties will remain the default value. New clients communicating with old services will also work, as the new properties will be ignored.
But as you can see, you will run into the problem of how can you ensure new clients communicate with new services, and old clients with old services? If this isn't an issue, then you don't have a problem. Otherwise you may need to introduce a new data contract.
Further reading:
MSDN Service Versioning
IBM Best practice for Web service versioning
Oracle Web services versioning
What are your WebService Versioning best practices?