I will soon release the next version of txtorcon with a ton of cool new features. This will be called 0.19.0. More details:
http://timaq4ygg2iegci7.onion/releases.html
Going forward, versioning will switch to a "CalVer.org" variant. At one point, I thought of breaking a few now-regrettable APIs.
However, I will not do this.
The next version after 0.19.0 will be 17.x.y Changes in any existing APIs will be done by first introducing the new thing, deprecating the old thing and eventually removing the old thing. The new documentation's "programming guide" includes some notes on API stability. I have not to date broken/changed any existing API. Also at this point nothing is deprecated (but there are "preferred" APIs).
The onion services APIs *will* change for the 17.x release.
New code should follow the recommendations in the programming guide. Existing code will continue to work for the forseeable future.
thanks, meejah
Hi meejah. This sounds like a good move since txtorcon makes so many small incremental releases. I like symantic versioning for stem [1], but I've only made six releases thus far. Not nineteen. :P
Symantic versioning provides a clear way of indicating what upgrades are safely backwards compatible and which aren't. In the above you say "The onion service APIs *will* change" but also "At one point, I thought of breaking a few now-regrettable APIs. However, I will not do this." - are you changing APIs or not?
If you are then Calendar Versioning will make it tricker for your users to figure out when you're doing so.
[1] https://stem.torproject.org/change_log.html#versioning
On Wed, Apr 12, 2017 at 1:25 PM, meejah meejah@meejah.ca wrote:
I will soon release the next version of txtorcon with a ton of cool new features. This will be called 0.19.0. More details:
http://timaq4ygg2iegci7.onion/releases.html
Going forward, versioning will switch to a "CalVer.org" variant. At one point, I thought of breaking a few now-regrettable APIs.
However, I will not do this.
The next version after 0.19.0 will be 17.x.y Changes in any existing APIs will be done by first introducing the new thing, deprecating the old thing and eventually removing the old thing. The new documentation's "programming guide" includes some notes on API stability. I have not to date broken/changed any existing API. Also at this point nothing is deprecated (but there are "preferred" APIs).
The onion services APIs *will* change for the 17.x release.
New code should follow the recommendations in the programming guide. Existing code will continue to work for the forseeable future.
thanks, meejah _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Damian Johnson atagar@torproject.org writes:
In the above you say "The onion service APIs *will* change" but also "At one point, I thought of breaking a few now-regrettable APIs. However, I will not do this." - are you changing APIs or not?
If you are then Calendar Versioning will make it tricker for your users to figure out when you're doing so.
The programming guide and docstrings mention which onion APIs are experimental; those will change.
The previously-released TCPHiddenServiceEndpoint and EphemeralHiddenService APIs will maintain backwards compatiblity. The names for the new things use "onion" (e.g. .create_onion_service)
Basically the idea is similar to (inspired by?) what Twisted itself provides: if your code doesn't currently cause txtorcon to emit warnings, then you can upgrade. Currently there are no warnings, so everyone can upgrade.
cheers,