Project

kvdag

0.0
No commit activity in last 3 years
No release in over 3 years
Directed Acyclic Graph for Key-Value searches
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
 Dependencies

Development

~> 1.13
~> 10.0
~> 3.0
~> 0.49

Runtime

 Project Readme

KVDAG

Implements a Directed Acyclic Graph for Key-Value searches.

Installation

Add this line to your application's Gemfile:

gem 'kvdag'

And then execute:

$ bundle

Or install it yourself as:

$ gem install kvdag

Usage

TODO: Write usage instructions here

Development

After checking out the repo, run bin/setup to install dependencies. Then, run rake spec to run the tests. You can also run bin/console for an interactive prompt that will allow you to experiment.

To install this gem onto your local machine, run bundle exec rake install.

Contributing

We are happy to accept contributions in the form of issues and pull requests on GitHub. Please follow these guidelines to make the experience as smooth as possible:

  • All development takes place in feature branches, with master only accepting non-fast-forward merges.

  • Others shall be able to use the KeyValue DAG library to build their own tools. If you introduce API changes, please increment version numbers according to semantic versioning.

  • All code will be reviewed before it is merged. To help the reviewer, send your work as a series of logically separate changes, not as one gigantic squash commit. Make sure bisection will work by ensuring the code actually works after each change.

  • GnuPG sign all your commits and tags, with a key that is validated by GitHub.

    • GitHub's web UI cannot generate signed merges when accepting pull requests. Instead, we use a custom tool to accept them. You can still send them through the web as usual.

    • Your code shall be signed by you. Therefore, the maintainer cannot fix any merge conflicts arising from your pull request. If there are any conflicts, please rebase onto current master before sending your pull request.

  • Document your work.

    • At an absolute minimum, Ruby code shall have RDoc blocks documenting each function.

    • Write your commit messages in the usual Git style: a short summary in the first line, then paragraphs of explanatory text, line wrapped.

  • Test your code.

    • Code shall pass Rubocop tests. See .rubocop.yml for configured options. Rubocop is automaticallly run with the default Rake task.

    • Tests shall be written in RSpec.

    • Library code shall have unit tests.

    • Tools shall have integration and end-to-end tests.