Skip to content

Commit

Permalink
Bump version to v0.10.0.
Browse files Browse the repository at this point in the history
  • Loading branch information
@TreyE
TreyE committed Feb 26, 2025
1 parent 9dc6324 commit 764df87
Show file tree
Hide file tree
Showing 4 changed files with 138 additions and 33 deletions.
23 changes: 23 additions & 0 deletions .github/release.yml
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
# Release notes template (https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes)

changelog:
categories:
- title: Breaking Changes 🚧
labels:
# Semver-Major
- breaking change
- title: New Features ✨
labels:
# Semver-Minor
- enhancement
- title: Bug Fixes 🐛
labels:
# Semver-Patch
- bugfix
- title: Other Changes 📦
labels:
- "*"
exclude:
labels:
- chore
- version bump
23 changes: 23 additions & 0 deletions .github/workflows/publish-release.yml
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
name: Publish Release

on:
push:
tags:
- v[0-9]+.[0-9]+.[0-9]+

permissions:
contents: write

jobs:
publish:
runs-on: ubuntu-latest

steps:
- name: Create release
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
gh release create "${{ github.ref_name }}" \
--repo="$GITHUB_REPOSITORY" \
--title="${{ github.ref_name }}" \
--generate-notes
70 changes: 37 additions & 33 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3,17 +3,15 @@
# @title README.md
# @author Dan Thomas
-->
# ResourceRegistry
[![Build Status](https://travis-ci.com/ideacrew/resource_registry.svg?branch=master)](https://travis-ci.com/ideacrew/resource_registry)
# ResourceRegistry

ResourceRegistry is a library for system configuration, feature flipping and eventing. It offers an approach to custom configuration for a single codebase, supporting use cases such as:
ResourceRegistry is a library for system configuration, feature flipping and eventing. It offers an approach to custom configuration for a single codebase, supporting use cases such as:

* Customer-level preference profiles
* Multitenancy
* Access control based on privilidges and subscriptions

ResourceRegistry is intended to address 'logic sprawl' that can occur with minimally- or un-structured key/value system settings schemes. It offers an
alternative to code obfuscation issues that often pops up when using Rails Concerns.
ResourceRegistry is intended to address 'logic sprawl' that can occur with minimally- or un-structured key/value system settings schemes. It offers an alternative to code obfuscation issues that often pops up when using Rails Concerns.

## Gem Features

Expand All @@ -31,29 +29,34 @@

### Installing on Rails

Add this line to your project's Gemfile:

Add this line to your project's Gemfile:
```
gem 'resource_registry'
```

And then execute:

And then execute:
```
$ bundle
```

Or install it yourself as:

Or install it yourself as:
```
$ gem install resource_registry
```

In your project build the directory tree to house configuration files:

In your project build the directory tree to house configuration files:
```
$ mkdir -p ./system/boot && mkdir -p ./system/config
```

Then, create Resource Registry's initializer file:

Then, create Resource Registry's initializer file:
```
$ touch ./config/initializers/resource_registry.rb
```

## Feature

ResourceRegistry uses a Feature to group related system functions and settings. Featurse are composed of the following high level attributes:
ResourceRegistry uses a Feature to group related system functions and settings. Featurse are composed of the following high level attributes:

* key [Symbol] 'key' of the Feature's key/value pair. This is the Feature's identifier and must be unique
* item [Any] 'value' of the Feature's key/value pair. May be a static value, proc, class instance and may include an options hash
Expand All @@ -62,7 +65,7 @@
* settings [Array<Hash>] a list of key/item pairs associated with the Feature
* meta [Hash] a set of attributes to store configuration values and drive their presentation in User Interface

Here is an example Feature definition in YAML format. Note the settings ```effective_period``` value is an expression:
Here is an example Feature definition in YAML format. Note the settings ```effective_period``` value is an expression:

``` ruby
- namespace:
Expand Down Expand Up @@ -90,9 +93,9 @@
item: :initial_sponsor_jan_default
```
### Registering Features
### Registering Features
Features are most useful when they're loaded into a registry for runtime access. For example:
Features are most useful when they're loaded into a registry for runtime access. For example:
``` ruby
require 'resource_registry'
Expand Down Expand Up @@ -150,9 +153,9 @@ my_registry[:greeter] {"Dolly"} # => "Hello Dolly"

### Namepace

Use the optional Feature#namespace attribute to organize Features. Namespaces support enable you to define a structure to group Features into a logical structure or taxonomy that can help with code clarity. For example:
Use the optional Feature#namespace attribute to organize Features. Namespaces support enable you to define a structure to group Features into a logical structure or taxonomy that can help with code clarity. For example:

``` ruby
```ruby
my_species = ResourceRegistry::Feature.new( key: :species,
item: :Operations::Species::Create.new,
is_enabled: true,
Expand All @@ -164,7 +167,7 @@ Namespaced Features respect their anscesters with regard to code access. For in

For instance, extending the ```species``` Feature example above:

``` ruby
```ruby
my_phylum = ResourceRegistry::Feature.new(key: :phylum,
item: :Operations::Phylum::Create.new,
is_enabled: false,
Expand All @@ -178,26 +181,27 @@ Namespaces serve another purpose: enabling auto-generation of Admin UI configura

## Rails Integration

A registry is configured and loaded when your application starts.
A registry is configured and loaded when your application starts.

## Configuration

The initializer and configuration files manage the setup and loading process.
The initializer and configuration files manage the setup and loading process.

Configuration files are located in your project's ```system/config``` directory. All Yaml files in and below this directory are autoloaded during the boot process. Configuration settings may be organized into directories and files in any manner. Values will properly load into the container hierarchy provided the file begins with a reference to an identifiable parent key.
Configuration files are located in your project's ```system/config``` directory. All Yaml files in and below this directory are autoloaded during the boot process. Configuration settings may be organized into directories and files in any manner. Values will properly load into the container hierarchy provided the file begins with a reference to an identifiable parent key.

An example of a simple configuration file:
An example of a simple configuration file:
```ruby
# ./system/config/enterprise.yml

```

## Defining Configuration Settings
## Defining Configuration Settings

### UI-ready configuration settings
### UI-ready configuration settings

## Credits
Based on [dry-system](https://dry-rb.org/gems/dry-system/) and [dry-validation](https://dry-rb.org/gems/dry-validation/1.0/) ```

Based on [dry-system](https://dry-rb.org/gems/dry-system/) and [dry-validation](https://dry-rb.org/gems/dry-validation/1.0/)

## Future Features

Expand All @@ -207,14 +211,14 @@ Namespaces serve another purpose: enabling auto-generation of Admin UI configura

## 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.
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`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).
To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).

## Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/ideacrew/resource_registry.
Bug reports and pull requests are welcome on GitHub at https://github.com/ideacrew/resource_registry.

## License

The gem is available as open source under the terms of the [MIT License](https://opensource.org/licenses/MIT).
The gem is available as open source under the terms of the [MIT License](https://opensource.org/licenses/MIT).
55 changes: 55 additions & 0 deletions RELEASING.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
# Release

This file describes the process for publishing a new version of the gem as a GitHub release.

Releases are managed through the [GitHub Releases](https://github.com/dchbx/resource_registry/releases) page.

Release names follow the [Semantic Versioning](https://semver.org/) standard.

Follow the steps below to package and release a new version of the gem.

## Major/Minor release
### Prepare the release
1. Checkout the main branch and pull the latest changes.
2. Create and checkout a branch - avoid naming the branch solely after proposed release number - something like 'rm12313453_v1.0.0._update_gemspec' might be ideal.
3. Update the version number in the `lib/<project>/version.rb` file. Note the [correct format](https://guides.rubygems.org/specification-reference/#version); only digits and dots are allowed. Do not include a `v` prefix.
4. Update the `Gemfile.lock` file:
- `bundle update --patch --conservative resource_registry` will generally reduce dependency bumps. Typically, other effects in the lockfile beyond the gem itself being bumped should be discarded.
- See bundler documentation for detailed information on how this [command](https://bundler.io/v2.5/man/bundle-update.1.html) behaves.
5. Commit the changes with a message like `bump version to v1.0.0`.
6. Push the branch and raise a pull request against the main branch. The pull request title should follow the format: `bump version to v1.0.0`. Be sure to label the pull request with the `version-bump` label.

### Publishing the Release
1. Once the pull request is approved and merged, checkout the main branch and pull the latest changes.
2. Create a new release branch in the pattern of `1.0.x-release`.
- Note: `x` is literal, to aid reuse of same branch for minor bugfixes.
3. Create a new annotated tag with the version number, e.g., `git tag -as v1.0.0 -m "v1.0.0"`.
- IMPORTANT: make sure the tag abides by the format `vX.Y.Z` where `X`, `Y`, and `Z` are integers. It is important that the tag name has a different format than any branch name to avoid confusion with Bundler.
4. Push the tag to the remote repository, e.g., `git push origin refs/tags/v1.0.0`.
- Avoid `git push --tags`, to not accidentally push random assorted local tags.
5. GitHub Actions will automatically create a new release on the [GitHub Releases](https://github.com/dchbx/resource_registry/releases) page with release notes. Confirm that the release was successfully published there and that all intended commits are included in the release.

## Patch/Bugfix release
### Prepare the release
1. Fix bug in the main branch, via normal PR process.

For any release that has the bug:
2. Create a temp branch off any live release branch that has the bug - pick a name that won't conflict with another branch or tag, as with Major/Minor step 2.
- Using a branch, which is then PR’d, ensures traceability and inclusion of an item in the generated release notes.
3. Cherry-pick the fix commits to the temp branch.
4. Update the gem `version.rb` file and `Gemfile.lock` as in Major/Minor release steps 3 and 4.
5. `git push` the temp branch.
6. Issue a PR to merge to the release branch.

### Publishing the Release
1. Once the pull request is approved and merged, checkout the release branch and pull the latest changes.
2. Create a new annotated tag with the version number, at the point of the release branch with the fix, e.g., `git tag -as v1.0.1 -m "v1.0.1"`.
3. Push the tag to the remote repository, e.g., `git push origin refs/tags/v1.0.1`.
- Again, better to avoid `git push --tags`.
4. Github Actions will create the release and pull in the fix PR's to the changelog.

## Using a Tagged Release in Another Project
To use the new release in another project, update the project's `Gemfile` to reference the release's tag, e.g., `gem 'resource_registry', git: 'https://github.com/dchbx/resource_registry.git', tag: 'v1.0.0'`.

## Git Process diagram
![Git Process Diagram - Gem](docs_assets/release_branching_gem.png)

0 comments on commit 764df87

Please sign in to comment.