Versioning
Closed this issue · 3 comments
Just ask to be clear about how you will set versions numbers for ShivyC releases.
- What is current major stable release?
- When 1.0.0 possibly coming?
REFERENCE
- Semantic Versioning 2.0.0 | Semantic Versioning
- https://en.wikipedia.org/wiki/Software_versioning
Hi Symbian9, thanks for your question. I'd like to follow semantic versioning going forward, and I expect that every time a new release is added on GitHub/pushed to PyPi, the new functionality added in that release will be generally ready for use and bug-free. So, I figure the latest release can be thought of as the latest major stable release.
I'm not sure what stage 1.0.0 should be released at, and I'm open to suggestions on this subject. The semantic versioning document you linked suggests releasing 1.0.0 when the tool is being used in production and has a stable public API. However, I'm not sure ShivyC will ever be used in a real environment, as GCC and Clang outdo ShivyC in pretty much every dimension someone would care about in a production compiler. Also, ShivyC doesn't have much of a "public API" per se, since the only interface with ShivyC is the single compilation command.
So, maybe, use second number as major release, and third number as bugfix
- v0.0.1 - initial release
- v0.0.2 - first bugfix release
- ...
- v0.1.0 - first major release
- v0.1.1 - first bugfix release for first major release (v.0.1.x branch)
- v0.1.2 - second bugfix release for first major release (v0.1.x branch)
- ...
- ...
- v1.0.0 - first production-ready release
Sounds good to me - let's stick to that plan going forward. At what point in development would you consider ShivyC to be "production-ready"?
(By the way, if you'd like to contribute to development, I've added some current TODOs labeled as Features under the Issues tab. Feel free to grab one if you're interested and I'd be happy to help explain any parts of the codebase that are unclear.)