Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Suggestions for 1.0 milestone #76

adelevie opened this Issue · 5 comments

5 participants


Discuss. Feel free to write the problem inline as a comment or just to link to an issue or PR.

Ideally, full parity with all of Parse's REST features would be nice. Wondering how others feel?

In some ways, I'm really happy with the stability of the codebase. Everything is pretty modular and magic-free. That said, some issues like delta-saving are still bugging me.


It's a good goal to get a stable release and then maintain release vs. development branches going forward. A lot of point releases have introduced bugs.

Parse::Date is the source of the most bugs/annoyance for us. Feels like a 1.0 requirement to kill that. Posting deltas could be a big performance improvement (and generally saner way to do things) but a big overhaul, might be good as a 1.1 target. Parse::Client might deserve some cleaning up pre-1.0 too, it has some commented out code and sort of a half-attempt at being threadsafe by pulling in a barely used IronMQ dependency. Seems best to ship a non-thread-safe synchronous client with a sane way to use multiple Parse::Client objects throughout an app. Right now everything refers back to @@client but it shouldn't be a huge amount of work to fix that so you can at least pass an optional client into everything. A future release milestone might be to abstract away the network request layer entirely so we're not in charge of network behaviors and retries but instead are just built as a layer on top of one of the HTTP futures frameworks.


Maybe we setup github pages for documentation purpose rather then maintain on big README.
Imho in readme there should be only most important things like warnings, not supported or beta features notes etc

@ericcj Did you see #88? Think this is the HTTP abstraction layer which you mentioned.


My wishlist for the 1.0 is:

  • remove Parse.init and @@client class variables
  • add #169 and #170
  • fix as much bugs as possible

Also, documentation (probably with YARD?) somewhere that isn't just the readme. README would be for instructions for development, some quick examples, and a link to common issues in the wiki (which is another thing to start developing).


Another thing for 1.0:

  • wiki page explaining how to migrate from 0.3.0 to 1.0
  • wiki page explaining what's new
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.