use semantic versioning & follow changelog standards

[rursprung]

i'd strongly suggest to move to using Semantic Versioning for this repository to make it easier for consumers to use it.

e.g. somewhere between 0.5.1 and 0.5.5 (presumably with 0.5.5 itself) support for rustc 1.42.0 has been removed (the minimum version required now is 1.54.0), so this should've been a 0.6.0 release instead.

using semantic versioning will clearly tell consumers what to expect when they update to a new version. also, the whole dependency version management system of cargo is built around semantic versioning (see the docs).

on a related note i'd suggest to move your changelog to follow Keep a Changelog to keep things more standardised (your changelog is already pretty closely aligned with this and will only need some minor enhancements for it to follow the standard).

[kubo]

Thanks. It is good opportunity for me to think about minimum supported rust version again.

i'd strongly suggest to move to using Semantic Versioning for this repository to make it easier for consumers to use it.

Rust-oracle has followed semantic versioning from the beginning (except for mistakes).

e.g. somewhere between 0.5.1 and 0.5.5 (presumably with 0.5.5 itself) support for rustc 1.42.0 has been removed (the minimum version required now is 1.54.0), so this should've been a 0.6.0 release instead.

I don't think that it is a breaking change. It depends on the policy of the maintainers (e.g. tokio, async-std) according to the cargo book.

In the cargo book, changing the minimum version of Rust required is categorized as "Possibly-breaking".

Possibly-breaking is:

The "Possibly-breaking" category covers changes that have the potential to break during an update, but may not necessarily cause a breakage. The impact of these changes should be considered carefully. The exact nature will depend on the change and the principles of the project maintainers.

I avoid using too recent rust versions. For example, I wrote code only working on rust 1.60.0+ (dep: prefix in the [features] table) in my local rust-oracle 0.6.0-dev branch just before and then I rewrote it to work on older ones. (Rust 1.61.0 is the latest stable release at present.) However I have not defined the policy. Your suggestion is good opportunity to define it.

on a related note i'd suggest to move your changelog to follow Keep a Changelog to keep things more standardised (your changelog is already pretty closely aligned with this and will only need some minor enhancements for it to follow the standard).

It is worth to adopt it partly. However I don't think that it is the standard at present. In the FAQ, "Is there a standard changelog format?" "Not really."

[kubo]

I added "Supported Rust Versions" to README.md.