yesterday evening we found quite a critical bug in remotestorage-01 https://github.com/remotestorage/spec/issues/23 which is quite ugly, but for now i think it doesn’t affect functionality, so it wouldn’t merit breaking our 6-months release cycle. i propose leaving it as it is until December.
It will break functionality if someone implements it according to spec and then hosts a website there. Visiting that website would break every second the same resource is requested.
So I vote for a new release sooner, but not before we haven’t tested more in practice - we may find more bugs.
i recognize your point, but just wanted to mention that hosting a website on remoteStorage is not best practice.
oh, but hosting images on public is… so it would break whenever you try to use the result of getObjectUrl() as the
src of an
I had no idea we had a 6 month release cycle. So I guess it really doesn’t matter
Release major fixes as soon as they are ready and the branch is stable, I would guess…
no, the release cycle matters. each time a new version of the spec comes out, clients have to add support for it. and at least every 3 times a spec comes out, servers need to switch (because we deprecate all but the latest 3 versions).
right now, since four weeks ago, servers need to support 2012.04 or -00 or -01, and clients need to support all 3 of those. implementers can be (almost) certain that if they do that, then they’re good until at least december 2013.
if we update at will then people will refrain from implementing remoteStorage, because they will say “looks like it’s not stable yet, i’ll wait a little bit” https://groups.google.com/forum/#!searchin/unhosted/freeze/unhosted/ojnYN3QPlxc/F83P9oKGfwcJ
i think we can argue that this is a case where two specs contradict each other, and add a note on http://remotestorage.io/provide/ saying everybody should let the http spec prevail here. it’s a bit cheeky, but it’s a quickfix that’s mostly painless. the risk is that someone misses that note, implements 412s for GETs, and finds out that it doesn’t work. but realistically, we can probably warn all server implementors on time before they run into that.
if you hear of someone implementing remotestorage-01 please alert them they should return 304s instead of 412s for GETs whose condition fails
RE: release cycle - I was mistakenly thinking about the client library, and not the spec, sorry for the confusion.