Definition

Those are my own definitions, that i know intuitively:

• If you have a service: any change that can break a client implementation without him changing anything.

• In a library or code: any API or behavior change that will force users of the API to change their code in order to continue using a new version.

You can find more dictionary like definition on Wiktionary

Identification

I identifying a breaking change is hard on developers since it force us to wear the hat of the user who uses our code.

Good testing culture, one that force creating unit tests (TDD anyone?) and UI automation tests helps in that regard. Makes it easier on the developer see the other direction, simply since he supposed to see it as part of his day to day job.

But even in the world of code to code APIs - breaking changes slip through unidentified simply since the language customers use and that used by the developers is usually not the same language.

In the world of on-line services and UI things are a lot worse.

Why do it?

Breaking changes to API is like refactoring to implementation.

If you do it in the correct amount, at the correct time, it helps your code grow.

If you do it at the wrong places, you end up costing to much to your customers that they will start abandoning your code/service and move on to other greener libraries/services.

Breaking changes can be forced on you for security reasons, design flows that needs to be corrected, unintuitive API/behavior that makes it harder than necessary to use your code/service.

They can be done as part of a new design or new vision. And they have the potential of opening new uses for your code that were closed before.

The right way

As with anything there is no one right way, but there are guideline:

• Since customers are paying the price, you need to notify them as early as possible, help them prepare.

• Always assume that there is a customer that will be hurt from that change, so try and identify them before hand and fix it with them in advance.

• If you can support multiple versions (using multiple/versioned APIs, or package management or any other means) do it and leave the old versions functional for a while.

• If possible deprecate the old behavior before you actually break it.

And even doing all that, breaking changes will have their price.

Culture

The hard part about breaking changes is not to define them, or identify them. It is making a sensible behavior around them.

• Create a culture that accept their role in your product.

• Understand and gives the place for the price that comes with those changes on the clients.

• Encourage everyone on the pipe to identify and communicate the breaking change and its price.

• And then implement the guidelines in the correct way for your project.

Think about it carefully

Make sure you do not hurt anyone

…do not hurt yourself

wait for the right time

against all feelings, wait

and then, at the right time

let it all out

on everyone

on everything

just out

free

This will probably be a series of posts, since it will be an ongoing project.

History

So lets start with the history:

• We had a few home computers that needed to share files between them. I considered NAS as an option, but dismissed it at the time for budget and headache reasons. Instead I used an old laptop as home entertainment center.
• That HP laptop lasted until its display dies, then we moved to a WD PowerBook 1TB.
• When that PowerBook died, we already got accustomed to have easy to access network storage, so we upgraded to WD MyCloud 2TB.
• That MyCloud died last week. After it had managed to also get us used to mobile backup.
• So now i am looking for a new replacement.

Requirments

This time I want to make a more informed decision. So I decided to start by looking at what it is I really want.

Data

I have data of several types:

• Documents - those I want backed up for every save, with the ability to revert to any of them. This is something I already have today using SparkleShare with butbucket.org as the backend. This works great except for large files.

• User files - basically this is all the other files in the user space. I want them backup on a regular fassion, but so far I have only had that on the same machine using ZFS snapshots. This is not a good solution, and I want a better solution. SparkleShare was not an option since it contained too much large files (Downloads for example) that I want to be able to remove from the history easily. And will clutter the history of my documents.

• Photos - All the photos we take, using our camera & phones. Up until now I backup up my photos to the network drive, and to a cloud service, glad that i did since that network drive is now dead. But i don’t trust the cloud service to be the only backup either. Also both options where not easy enough for cataloging and organizing unless i sync a local folder with them, something that is simply not possible due to size of the collection.

• Downloads - All apps, drivers, media files, documents, etc. that we download from the world. Those all have limited lifespan, each being downloaded, used for a while and then discarded. They do not need versioning or snapshots, instead they need an origin documentation, easy large storage.

network

Basically I manage today 3 home networks: at my home, my mother and my grandmother. And I also use and sometimes interfere with the networks at my sister and my father-in-law’s.

Up until now my storage solution was limited just to my home network, but i have been thinking for a while on replicating it across those different locations so that i will have access to my files in all those locations, as well as backup.

So whatever solution I will choose eventually, i will want it to be open for replication (probably using torrent sync of incremental snapshots)

Features

So lets review the features required by me for my data and netwrok.

• Capacity: at least 4TB or real storage but I will want to grow it over time. With the overhead for HD redundancy and file overhead - will probably be around 6TB.

• Swap drived: I’ll need the ability to swap drives and continue. Not necesarily a hot swap, I don’t mind shutting down to do it.

• Network connectivity: It will have to be able to connect to my wired ethernet

• NFS/SMB Share.

• UPNP/DLNA Media streaming