-
Notifications
You must be signed in to change notification settings - Fork 8
Early Development Guide
This guide is for those wishing to contribute to Authoreyes during its early stages of development (pre v1.0.0).
For the current development status of Authoreyes, see the Issues and this page.
Contribution to Authoreyes is most welcome! Simply fork the repo and code away! Pull Requests should be made into Authoreyes's edge branch. The master branch should reflect only the gem as it currently stands on RubyGems. Commits pulled into edge will be built, merged to master, and pushed to RubyGems.
When developing Authoreyes, please observe the following guidelines:
- Initial target is Rails 5 on Ruby 2.3.
- All new code should have tests. Minitest is used here, and specs are preferred.
- All new code should be documented (RDoc / YARD preferred) using in-source, comment-style documentation.
- All new code should be formatted according to Rubocop's guidelines for ruby styling.
- The Ruby Style Guide includes things such as 2-space soft tabs, etc.
- Submit pull requests to the
edgebranch. - Do not change the version number. Make a note of changes on the Pull Request and gem maintainers will change the version number appropriately before building and pushing to RubyGems.
Before the v1.0.0 milestone is reached, the first development priority is to mirror the most desired functionality of Declarative Authorization, as this gem is designed to be a modernized replacement for it for Rails 5.
These are the development guidelines and goals for the v1.0.0 milestone:
- DO NOT simply copy and paste code from Declarative Authorization.
- Authorization files from apps using Declarative Authorization should (ideally) work as-is with Authoreyes.
- Ideally, v1.0.0 should work as a drop-in replacement for Declarative Authorization, at least in terms of DSL syntax, and the ability to support model, view, and controller syntax from Declarative Authorization.