Thanks for helping improve ruby_api_pack_core. This gem is maintained by
PHCDevworks as the shared HTTP client foundation for every ruby_api_pack_*
gem — it has no vendor-specific knowledge of its own.
- Clone the repository.
- Install dependencies with
bundle install. - Run
bundle exec rspec. - Run
bundle exec rubocop. - Build the gem with
gem build ruby_api_pack_core.gemspecwhen preparing a release or changing packaging metadata.
lib/ruby_api_pack_core.rb: public gem entry pointlib/ruby_api_pack_core/configurable.rb: sharedconfigure/configurationsingleton mixinlib/ruby_api_pack_core/connection/base.rb: shared HTTParty/Oj connection template classlib/ruby_api_pack_core/handlers/response_validator.rb: shared response-shape validatorlib/ruby_api_pack_core/version.rb: gem versionspec/: RSpec coverage for the connection base class, validator, and configurable mixin, tested against synthetic dummy classes
- Keep public method names stable
(
api_get/api_post/api_put/api_delete,validate_response,configure/configuration) unless the change is intentionally breaking. - Add or update focused specs for any behavior change, exercised against a dummy subclass or dummy module — never against a real vendor API.
- Keep this gem free of vendor-specific knowledge. If a change requires
knowing which third-party API is being called, it belongs in a consuming
ruby_api_pack_*gem instead. - Any breaking change here must be coordinated with
ruby_api_pack_active_campaign,ruby_api_pack_cloudways, andruby_api_pack_wordpressbefore or alongside release.
- Follow the repo's RuboCop configuration.
- Prefer small, pattern-aligned changes.
- Keep comments brief and only add them when they explain a non-obvious reason.
- Preserve unrelated local changes.
- Do not create commits, tags, releases, or publish gems unless explicitly asked by a maintainer.
Use this checklist when touching any public behavior surface:
lib/ruby_api_pack_core.rblib/ruby_api_pack_core/configurable.rblib/ruby_api_pack_core/connection/base.rblib/ruby_api_pack_core/handlers/response_validator.rbREADME.md
Before merge:
- Update or add focused specs.
- Run
bundle exec rspec. - Run
bundle exec rubocop. - Build with
gem build ruby_api_pack_core.gemspecwhen packaging metadata changed. - Update
README.mdif installation, usage, or contract guidance changed. - Update
CHANGELOG.mdunder[Unreleased]. - Classify the change as additive, behavior change, breaking, or docs/config only in the pull request.
- If the change is breaking, note the required follow-up in the three consuming gems.
- Keep the change focused.
- Fill out every section of
.github/pull_request_template.md. - Link an issue or write
N/A. - Include a concise summary and reviewer notes.
- Leave blocked checklist items unchecked with a short note.
For maintainers, a release should keep these records aligned:
- Update
lib/ruby_api_pack_core/version.rb. - Move relevant
CHANGELOG.md[Unreleased]notes into a dated version entry. - Run
bundle exec rspec. - Run
bundle exec rubocop. - Build the gem from the matching source state.
- Confirm the three consuming gems still pass their own validation gates against the new version, if the change is anything other than additive.
- Publish release notes from the matching changelog entry.
Open an issue if you need direction before making a larger change.
By participating in this project, you agree to follow the Code of Conduct.
By contributing, you agree that your contributions will be licensed under the MIT License.