Suggestions for 1.0 milestone

[adelevie]

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.

[ericcj]

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.

[dgertych-monterail]

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.

[rhymes]

My wishlist for the 1.0 is:

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

[xavdid]

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).

[rhymes]

Another thing for 1.0:

• wiki page explaining how to migrate from 0.3.0 to 1.0
• wiki page explaining what's new

[xavdid]

@rhymes So I was thinking- I think the client change was the only big breaking change we're going to do- a lot of the other changes are features and stuff.

Why don't we go ahead and cut the 1.0.0 release and then have all of the extra, currently missing parse features be minors after that?

Alternatively, we could burn simple tasks like adding features TODO in the readme (such as deleting objets, etc) for a real v1 feeling, then cut the release?

[rhymes]

@Xavdidtheshadow Yep, we could do that, I feel that before though we should increase the test coverage a bit, review the doc (see also #190), write a changelog (we can use git-extras for that https://github.com/tj/git-extras/blob/master/Commands.md#git-changelog) and some sort of migration guide?

[xavdid]

Is there an easy place to see where we're missing test coverage on existing code?

Totally. I'll go through tomorrow and make a set of tasks we should actually get ready for 1.0 and when those are done, we can release!

[rhymes]

@Xavdidtheshadow only locally, I'll enable coveralls later on the repository so we can all see it. Thanks!

[rhymes]

@Xavdidtheshadow https://coveralls.io/github/adelevie/parse-ruby-client?branch=master here you are :D I also added the badge in the README

[xavdid]

@rhymes nice! that's way more than I thought it would be- it seems like we're in pretty good shape.

[rhymes]

yes indeed :)