Jacek Sieka

based on discussion today, a preferable approach would be to keep the current semaphores in place, but _also_ offer forced dialling as an option, which then would be measured against...

eh 1.0 would imply api stability, don't thing this project is there yet

regardless of the stability of the code itself, we're running on top of an unstable api / abi, meaning that when libp2p changes projects that depend on it have to...

> needs to remain stable to not break production code. or the production code users need to be aware that the abi is not stable, either is fine - version...

here's a sample of breaking changes from last week: https://github.com/status-im/nim-libp2p/pull/495 https://github.com/status-im/nim-libp2p/pull/490 https://github.com/status-im/nim-libp2p/pull/480 but sure, if you want to police a major version update for each of of these, you can...

> no semantic versioning a bit pointless to do versioning without meaning - semantic versioning provides a framework that nobody has bested yet > drop versioning well, yes, until the...

> there is no information about backward compatibility when updating to a later commit. there is information: every commit can be expected to break it, as is practically the case...

well, it is in the nature of things that they get used in "production" before becoming stable by pioneering projects - in terms of managing expectations though, 1.0 usually implies...

upnp/natpmp would be enough - we're using https://github.com/status-im/nim-nat-traversal - at some point in a distant future we might do a pure nim version as well, but that's not too urgent....

Related eth2 ticket: https://github.com/ethresearch/p2p/issues/4