Without this small addition you might just concentrate on storing and loading the data. With it you might take the time to add a simple format version number to your file which will make your life much easier in the future.
It doesn't take much work to add the version number, it just takes forethought or experience. Without it, you have to hope that newer versions can use something else to determine what format the file is (new or old / how old), often certain content or absence of it.
Standard and flexible file formats like XML can sometimes help this problem since you can read the file without knowing what to expect, but often this same consideration of having the new work with the old crops up in other areas.
Whether its two versions of the same software or two entirely different programs, any point of interaction between them becomes an API. Sometimes that is intended, sometimes not. The format of the saved file doesn't seem like an API when its first written, but the future versions make it so.
Where the API is intended the knock on effects of an API-breaking change are usually considered more thoroughly. The Windows API, while perhaps not being the best example of a well defined API has at least (on the surface anyway) maintained its interfaces for a very long time. In fact, the maintenance of its APIs has been key to Microsoft's success and continued existence.
Unfortunately for many Java developers Oracle seems on a number of occasions not to be overly concerned with breaking API and this is something we try and automatically guard apps agains in JWrapper.
If some software is designed and created as a library for other software to use then there is clear intention and often the developers will be thinking ahead about the effects of changes. Where the API isn't intended things get more muddy.
We recently had a case where a customer let us know that on Suse Linux, gksudo had changed to gnomesu. Gksudo is a command in Linux which is used to elevate other commands. Here's an example window that you would see when its run:
We provide an API in JWrapper that uses this under the covers when you need to launch a virtual app with elevated access. Because Linux is quite a fragmented system we also support a number of other options like pkexec and kdesudo. We aren't alone in this method, it makes a lot of sense. Without using something like gksudo or pkexec we would have to basically go and write it ourselves including the UI, translations and so on.
Gksudo, pkexec, kdesudo - these are individual commands. Apps written for Linux by a contributor that made them freely available and they are used by both developers and Linux users. They take parameters and produce a return code just like any other app but in doing so they also create their own implicit API.
As gksudo becomes more popular and widespread, scripts and software are written to use it. They rely (partially) on its existence, its parameters and its return code. Over time this can build up to quite a lot of software out there that is hoping or expecting that gksudo will be available.
With gnomesu replacing gksudo, this may be a welcome change. I haven't personally investigated the details but there may be some benefits to its replacement. What isn't a benefit is that on systems where gnomesu has replaced it, gksudo no longer exists. The API has changed in a way that couldn't earlier be predicted - a breaking change.
One could look at this and say it is just progress, a necessary change to bring in these benefits, but another way to look at it would be to ask 'how much work would it have been to make it backwards compatible?'.
On systems where gnomesu replaced gksudo, could a script, another app or just a simple symlink have left a virtual 'gksudo' command in place which actually used gnomesu under the covers? This doesn't sound like a lot of work, and it likely isn't, but because whoever took the decision to replace gksudo with gnomesu was likely thinking in terms of 'improved app A replacing old app B' rather than thinking about this as an API, it hasn't happened.
Adding this shim wouldn't have been a big job, it might have taken one developer less than a day to implement. Handling the addition of gnomesu and the demise of gksudo may not be a big deal for people who have scripts or software that use it, but it does force them into the position of having to update to get things working again, and it has that effect times hundreds, thousands, or maybe a lot more depending on how many have been relying on it.
Its easy when thinking of software maintenance to think 'what is there to maintain?'. Software doesn't age and decay like a house or wear out like a car. It's just logic, given the same environment it will run until the end of time in exactly the same way, producing the same results. If you load up an old game on an old computer it will work just the way it did back when it was written:
When it comes to maintenance, software developers are their own collective worst enemy but being aware of your own unexpected and implicit APIs can often save some headaches down the line.