Development Experience(s)

Versioning is hard. The first rule of Versioning is don't do versioning , meaning - if we are at all able, we should try to find ways other than versioning components to coordinate upgrades of the same. Let's start there. If you have component that you wish to expose to a third party - a service  of some kind - and you resist the temptation of creating a generic interface to that service, but instead create a specific interface for that consumer, you will have little reason to change this interface in the future, when you need to cater to another consumer. I've gone into more details in a previous blog post, so I'll just refer you there . When you do need to do versioning, however, there are some strategies you can follow to avoid the dreaded breaking change  scenario, where one or more of your consumers stop working, until they are in sync with your recent changes. The particular strategy explained below, has been tested with WCF Services (using XML serialization

Introduction With the web application platform quickly evolving, we are under a constant bombardment of new features, frameworks and techniques. Some of these, such as Web Components  ( Polymer ), enables us to revisit ideas from the past, such as Web Mashups ( 2003 , 2006 ). The underlying idea of both mashups and components, is to use small pieces of functional UI and assemble them into larger solutions / applications. As the Web Components are maturing / finishing cooking, I have an alternate (or intermediate) solution I'd like to discuss with you. Background Why this article? As the amount of software we produce (and thus need to maintain) in our company increase (while shifting focus to meet the market and rotating some of our staff (consisting of about 50% contractors in some parts of the organization)), our development teams are struggling to deliver consistent quality. This is expressed in a difficulty to ensure green builds (no unit & integration test failures