DISCUSSION: Backwards compatibility

[robla]

Over in issue #3 , @brainbuz made the following comment.

As the author of another voting library that has formats which will be deprecated the moment ABIF becomes official, I do not think backwards compatibility with other formats should be a concern.

Backwards compatibility with a single implementation shouldn't be a concern if/when there are 50 implementations of ABIF, and 49 of those implementations all implement things one way, with the 50th choosing something different. This assumes that the 50th implementation isn't widely used, and that there haven't been a lot of important ABIF documents created by users of that implementation. It also assumes that the author of that 50th implementation is a living member of the ABIF community, and is actively developing ABIF software that they can be convinced to change. In many other cases, backwards compatibility is a concern.

As I stated my June 16 comment on issue #6, I would like to maintain compatibility in the ABIF specification with this example:

42:Memphis>Nashville>Chattanooga>Knoxville
26:Nashville>Chattanooga>Knoxville>Memphis
15:Chattanooga>Knoxville>Nashville>Memphis 
17:Knoxville>Chattanooga>Nashville>Memphis

@brainbuz wasn't objecting to this example being valid, but my fear is that @masiarek might be making an argument against it in his comment yesterday on issue #19. He seems to be arguing that ranking numbers should be required in all ABIF files and that candidate tokens should be optional (with the first column being reserved for "Memphis" in all four lines. This would go against 25 years of precedent within the EM-list community and in the broader electoral reform community. The example above is "brainspace compatible" with many of us, and until we die or stop caring about electoral reform, I suspect that many of us will want to continue writing software that parses that example.

Let's use the "Discussions" feature on Github to discuss backwards compatibility, rather than discussing it in the comments of an issue. I wrote much of this message when I was replying to @brainbuz in issue #3, but now I realize that this is the perfect thing to use the "Discussions" feature for. How much concern should we have with backwards compatibility with other implementations? Which implementations do we care about? Which ones don't we care about? My current bias is to reward early adopters of ABIF by sticking to our original design decisions, but since there's not (yet) an "official" specification, I'll just stipulate that "electorama/abif" is going to be pretty conservative about making changes to design decisions.

[brainbuz]

In the comment pasted over I was specifically talking about backwards compatibility with pre-ABIF formats, once ABIF is officially released, parsers written to future versions should be able to read files from the original version.