our version implies we are stable, are we?

[astrale-sharp]

as can be seen here there is a meaning with having a version superior to 1.0.0, we already changed the interface in backward incompatible ways, shouldn't we regress our version to something like 0.2._ ?

[MatejSloboda]

Possibly. Jumping to 1.0.0 was probably a mishap on my side. That said, I believe the public interface is stable now. I don't expect any major changes to the interface in the near future. Maybe except adding new features.

[MatejSloboda]

Maybe we should pinpoint what exactly do we mean by "backwards incompatible". The way I understand it, in context of Godot GDNative, and this project in particular, is that, it's compatible if:

1. user is using older version of "_Dijkstra_maplibrary" folder (the one with binaries and nativescript files) in their project.
2. user downloads newer version.
3. user replaces their old "_Dijkstra_maplibrary" folder in their project with the new one.
4. their original project didn't break due to this upgrade

Backwards compatibility is not broken by:

• changes to the examples, tests and documentation
• bug fixes (note: if user's code relies on a bug, it may break)
• changes that do not affect public API or functionality in any way (optimizations, refactoring, etc.)
• changes that strictly add new functionality, without changing old functionality
• adding additional binaries for new targets

I'm not sure whether changes to the Rust public API (ie. stuff in the "dijkstra-map" folder) should count, if they don't affect the GDNative interface (ie. stuff in the "dijkstra-map-gd") that is actually exposed to Godot. Should we consider users who use the dijkstra-map as a Rust crate? (and are there any?) Or should we only consider the Godot users who use this as GDNative script?

[arnaudgolfouse]

I think you are right that the Rust API in "dijkstra-map" should not count toward backward compatibility, especially since it has it's own version in the Cargo.toml file (0.1.0 at the moment if I am not mistaken)