Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Suggestions for 1.0 milestone #76

Open
adelevie opened this Issue Apr 8, 2013 · 12 comments

Comments

Projects
None yet
5 participants
Owner

adelevie commented Apr 8, 2013

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.

Contributor

ericcj commented Apr 10, 2013

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.

Contributor

chytreg commented Apr 29, 2013

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.

@xavdid xavdid added discussion and removed awesome_to_have labels Jun 1, 2015

Collaborator

rhymes commented Jun 19, 2015

My wishlist for the 1.0 is:

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

xavdid commented Jun 19, 2015

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

Collaborator

rhymes commented Jun 21, 2015

Another thing for 1.0:

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

xavdid commented Oct 13, 2015

@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?

Collaborator

rhymes commented Oct 13, 2015

@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?

Collaborator

xavdid commented Oct 13, 2015

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!

Collaborator

rhymes commented Oct 13, 2015

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

Collaborator

rhymes commented Oct 14, 2015

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

Collaborator

xavdid commented Oct 15, 2015

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

Collaborator

rhymes commented Oct 15, 2015

yes indeed :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment