Versions

The first version of the specification is 0.5. Prior to that, there was no specification. There were only various versions of InPUT4j, and whatever implicit specification their behavior reflected.

InPUT v0.5 is currently being developed by simply describing InPUT4j v0.5. Whatever behavior that program exhibits, that is, by definition, what it means to be an InPUT implementation. This has the unfortunate side-effect that bugs have to get locked into the v0.5 specification.

It may sound reasonable that bugs should be taken into account, and the sensible behavior should be described in the specification, rather than the erroneous behavior that only exists by accident. The problems with that approach are twofold. For one, it is difficult for anybody other than the creator of InPUT4j to know what really constitutes a bug. After all, where does it say what the program should actually be doing? Secondly, the process would involve much more back-and-forth between testing InPUT4j, reporting the results and figuring out whether or not the results indicate a bug, fixing that bug, possibly revising the documentation, and so on.

The strategy currently being employed instead is the following. The current version of InPUT4j is examined by extensive testing. A specification is produced as quickly as possible, without waiting for bug fixes. Then the specification can be revised and updated with arbitrary changes. That way, an official and detailed specification of what InPUT should actually do can be produced faster. This makes it easier to create new implementations sooner, and it should even help adapt InPUT4j to the new, bug-free specification, with the help of the test suite.

In a sense, v0.5 describes what is true. Future version will prescribe what should be true.