On Aug 27, 2014, at 02:52 PM, Florian Fuchs wrote:
We're still in beta, so I think breaking backwards compatibility is justifiable (we should probably coordinate the release of the affected packages though).
Cool, and yes, definitely.
If we want to make our lives a little easier we could keep the "address" and "password" properties as proxy attributes in mailman.client to minimize the risk of things breaking. At least for a while.
That sounds reasonable.
In the future (once we're out of beta) we could mabye just bump up the API version number in cases like that. BTW: Should the API version nr always correspond with the core's version number? Like core version 3.0.12 => "http://localhost:8001/3.0"?
That was my original plan. It means that within beta releases, the API would be free to change (I'm not sure /3.0.12b1 would be worth it). TBH I haven't actually tried to see what it would mean to rev the API version path component. Maybe it could insert a flag on the request that end-points could refer to if they wanted emit some different JSON, or some responder along the path could dispatch to a different end-point if needed. In theory <wink>, it seems quite doable.
I'm really hoping the falcon guys will accept my patch, or at least work with us to get restish-style dispatch working. I *really* want to switch to falcon.
Cheers, -Barry