This has popped out before without leaving much of a trace. With 1.0 knocking at the door, I'd like to start a discussion by writing down my thoughts. Ideally this thread should give birth to a properly documented versioning scheme for OpenTK.
Major - major architectural changes, substantial parts (or all) of library rewritten or new, major changes in GL/AL/CL, breaking changes
Minor - internal changes spanning across several classes/parts of library, new bits of GL/AL/CL exposed, a large amount of bugfixes, backward compatible (unless...?)
Revision - class-bounded internal changes, "average amount" of bugfixes, added method overloads for convenience (without new functionality), backward compatible.
In order to keep it simple I propose to NOT introduce a build number, and use the denominations "alpha", "beta", "rc" followed by a number only with breaking changes.
Another proposal would include the date/time into the version signature. I'm not too keen on that basically because I never know what's happened in between. Tracking the precedent/follow up version is not simple either, if the library isn't released regularly.
I hope you have a couple of minutes to put down your idea and explain why it should/shouldn't be used by OpenTK.
Edit: use the denominations "alpha", "beta", "rc" followed by a number only with breaking changes.