Please start adding version tags

[ellemenno]

Ash is already stable, so version tags would help users track bug fixes and enhancements.

Also, this implementation is the reference for ports, so a version tag would help the ports declare compatibility levels.

[richardlord]

It's not just stable, it's complete bar very occasional bug fixes and performance improvements. I can add a 1.0 tag but with no future updates planned it seems superfluous.

[ellemenno]

Great, a 1.0.0 tag would be awesome, thanks! (and those rare little bug fixes could get a 1.0.1 and 1.0.2 etc.)

[richardlord]

Like I said, I can do it but it seems superfluous. You need to convince me of the value in doing so, particularly since the correct 1.0.0 tag would have been some months ago.

[ellemenno]

Wow, I'm suprised at your resistance. Do you not think versioning is a key feature of a code library?

You mentioned in your comment above that Ash sees an occasional bug fix. I see an api change just merged as well.

Code dependent on one version of a library might break on a different version of the same library, so being able to specify an exact version of the library to link against makes builds reproducible.

If I'm porting Ash to another language. I'd like to indicate feature parity or big fix parity. It would be very easy to do this if I could reference a tag pointing to a specific release of the reference library.

If you haven't seen it before, semver.org has a nice straight-forward spec for a major.minor.patch style versioning system.

[richardlord]

This project is not in active development. I think versioning a completed project, which runs on a dying platform, for which the correct version 1.0 would have been two years ago, is potentially confusing for people.

Tell me why I should add a version 1.0 now, when the project is completed and the implication of doing so would be to incorrectly tell developers "At last it's ready for production use"? It's been ready for and in production use for the past two years.

I could go back over the last three years and add version numbers at key points. In that case the current version would probably be 1.3.3 or something. But why disrupt a stable, completed project like that? It seems to me that would be a wasted effort that may lead to confusion and questions from developers who are happily using the project.

Version numbers are useful to projects that are in active development while also being used. Ash is not in active development.

P.S. There was no API change in the recent merge. The most recent API change was the addition of the engine state machine eleven months ago.