search

fgrehm / vagrant-cachier

Caffeine reducer
http://fgrehm.viewdocs.io/vagrant-cachier
MIT License
1.08k stars 111 forks source link

How does our 1.0 look like? #31

Closed fgrehm closed 10 years ago

fgrehm commented 11 years ago

Should we have a set of goals to accomplish for us to reach 1.0?

/cc @patcon @cromulus

patcon commented 11 years ago

Good call. I'll create a milestone and see if I can cruise through the queues later

patcon commented 11 years ago

What you mentioned here makes sense as a starter: https://github.com/fgrehm/vagrant-cachier/pull/30#discussion_r5250988

I'll add those, but feel free to remove.

Should we have a certain goal for retrofitting test coverage?

cromulus commented 11 years ago

I agree, specs are gonna be increasingly necessary, perhaps a travis-ci setup?

I personally want to get #4 done.

fgrehm commented 11 years ago

@patcon @cromulus :+1: for all of that and some refactorings as well, there's lots of copy & paste around buckets code ;)

fgrehm commented 11 years ago

BTW, what do you guys think about moving the documentation out to the wiki?

patcon commented 11 years ago

Usually not a fan of wiki's because it's harder to enforce that all PR's come with corresponding doc changes. Easier to get out of sync.

However, kinda a pain that doc changes still need to go through our PR workflow. Is that the rationale?

fgrehm commented 11 years ago

TBH it is more about keeping the README small with just the basic stuff (maybe just talk about auto_detect and enable_nfs which is what most people are going to use) and put the docs somewhere else. the idea would be to follow the same approach Sidekiq and my own vagrant-lxc follows

another option would be to document our classes with rdoc and add a link to http://rubydoc.info/gems/vagrant-cachier/0.2.0/frames on the readme, this would keep PR's with corresponding doc changes and would put the readme on a diet ;)

patcon commented 11 years ago

Sorry, I just criticized and didn't explain what I thought might be a great alternative. I find that creating a doc/ directory with a bunch of sensibly arranged files works well. Then the PR workflow dilemma is resolved. The composer project uses this approach and also generates the official website from these docs (not that we need this now):

https://github.com/composer/composer/tree/master/doc http://getcomposer.org/doc/

Would that work?

fgrehm commented 11 years ago

Yup that would do :) I just want to keep the README with the basics to make the plugin work and direct users to the docs in case they need more info

fgrehm commented 11 years ago

Quick update: I've added some more stuff to 1.0.0 but forgot to keep track of what have changed :P please have a look at the milestone issues for the list :)

fgrehm commented 10 years ago

Ok folks, I've just updated our milestone and I'll do my best to keep it up to date :-)

If someone else has any input on it, please raise your hand!