Misc: code formatting, doc comments, CI updates

.github/workflows/ci.yml

@@ -3,17 +3,18 @@ on: push
 jobs:
   test:
     runs-on: ubuntu-20.04
-    name: OTP ${{matrix.otp}} / Elixir ${{matrix.elixir}}
+    name: OTP ${{matrix.versions.otp}} / Elixir ${{matrix.versions.elixir}}
     strategy:
       matrix:
-        otp: ['26.2.5']
-        elixir: ['1.17.0']
+        # Minimum and maximum supported versions
+        versions: [{ elixir: '1.14.0', otp: '25' }, { elixir: '1.18.0', otp: '26.2.5' }]
     steps:
       - uses: actions/checkout@v4
       - uses: erlef/setup-beam@v1
         with:
-          otp-version: ${{matrix.otp}}
-          elixir-version: ${{matrix.elixir}}
+          otp-version: ${{matrix.versions.otp}}
+          elixir-version: ${{matrix.versions.elixir}}
+      - run: mix deps.unlock --all # compiles and runs tests against latest versions of dependencies
       - run: mix deps.get
       - run: mix test
       - run: mix dialyzer --format github

CHANGES.txt

@@ -1,11 +1,11 @@
-0.2.0 (February XX, 2025):
+0.2.0 (February 14, 2025):
  - Added new variations of the get treatment functions to support evaluating flags in given flag set/s: `Split.get_treatments_by_flag_set/3`, `Split.get_treatments_by_flag_sets/3`, `Split.get_treatments_with_config_by_flag_set/3`, and `Split.get_treatments_with_config_by_flag_sets/3`.
  - BREAKING CHANGES:
     - Removed the `fallback_enabled` option from `Split.Supervisor.start_link/1`. Fallback behavior is now always enabled, so `Split` functions no longer return `{:error, _}` tuples but instead use the fallback value when an error occurs.
     - Renamed the `Split.Treatment` struct to `Split.TreatmentWithConfig` and removed the `label`, `change_number`, and `timestamp` fields.
     - Moved the `Split` struct to the new `Split.SplitView` module and updated some fields: renamed `configurations` to `configs`, `flag_sets` to `sets`, and added the `impressions_disabled` field.
     - Updated the return types of `Split.get_treatment/3` and `Split.get_treatments/3` to return a treatment string and a map of treatment strings, respectively.
-    - Updated all `get_treatment` function signatures: removed the third argument (`bucketing_key`) and expanded the first argument (`key`) to accept a union, allowing either a string or a map with a key and optional bucketing key (`{:matching_key, String.t(), :bucketing_key, String.t() | nil}`).
+    - Updated all `get_treatment` function signatures: removed the third argument (`bucketing_key`) and expanded the first argument (`key`) to accept a union, allowing either a string or a map with a key and optional bucketing key (`%{required(:matchingKey) => String.t(), optional(:bucketingKey) => String.t() | nil}`).
 
 0.1.0 (January 27, 2025):
  - BREAKING CHANGES:

CONTRIBUTORS-GUIDE.md

@@ -9,13 +9,14 @@ Split SDK is an open source project and we welcome feedback and contribution. Th
 3. While developing, use descriptive messages in your commits. Avoid short or meaningless sentences like: "fix bug".
 4. Make sure to add tests for both positive and negative cases.
 5. If your changes have any impact on the public API, make sure you update the type specification and documentation attributes (`@spec`, `@doc`, `@moduledoc`), as well as it's related test file.
-6. Run the build script (`mix compile`) and the static type analysis (`mix dialyzer`) and make sure it runs with no errors.
-7. Run all tests (`mix test`) and make sure there are no failures.
-8. `git push` your changes to GitHub within your topic branch.
-9. Open a Pull Request(PR) from your forked repo and into the `development` branch of the original repository.
-10. When creating your PR, please fill out all the fields of the PR template, as applicable, for the project.
-11. Check for conflicts once the pull request is created to make sure your PR can be merged cleanly into `development`.
-12. Keep an eye out for any feedback or comments from Split's SDK team.
+6. Run the code formatter (`mix format`) and verify that all files are properly formatted.
+7. Run the build script (`mix compile`) and the static type analysis (`mix dialyzer`) and make sure it runs with no errors.
+8. Run tests (`mix test`) and make sure there are no failures.
+9. `git push` your changes to GitHub within your topic branch.
+10. Open a Pull Request(PR) from your forked repo and into the `development` branch of the original repository.
+11. When creating your PR, please fill out all the fields of the PR template, as applicable, for the project.
+12. Check for conflicts once the pull request is created to make sure your PR can be merged cleanly into `development`.
+13. Keep an eye out for any feedback or comments from Split's SDK team.
 
 # Contact
 

README.md

@@ -9,7 +9,7 @@ This SDK is designed to work with Split, the platform for controlled rollouts, w
 
 ## Compatibility
 
-The Elixir Thin Client SDK is compatible with Elixir @TODO and later.
+The Elixir Thin Client SDK is compatible with Elixir v1.14.0 and later, and requires [Splitd daemon](https://help.split.io/hc/en-us/articles/18305269686157-Split-Daemon-splitd#local-deployment-recommended) v1.2.0 or later.
 
 ## Getting started
 
@@ -30,7 +30,9 @@ After adding the dependency, run `mix deps.get` to fetch the new dependency.
 
 ### Using the SDK
 
-Below is a simple example that describes the instantiation and most basic usage of our SDK. Keep in mind that Elixir SDK requires an [SplitD](https://help.split.io/hc/en-us/articles/18305269686157-Split-Daemon-splitd#local-deployment-recommended) instance running in your infrastructure to connect to.
+Below is a simple example that describes the instantiation and most basic usage of our SDK.
+
+**NOTE:** Keep in mind that Elixir SDK requires an [Splitd daemon](https://help.split.io/hc/en-us/articles/18305269686157-Split-Daemon-splitd#local-deployment-recommended) instance running in your infrastructure to connect to, with the link type set to `unix-stream`.
 
 ```elixir
 # Start the SDK supervisor
@@ -43,7 +45,7 @@ case Split.get_treatment(user_id, feature_flag_name) do
   "off" ->
     # Feature flag is disabled for this user
   _ ->
-    # "control" treatment. For example, when feature flag is not found or Elixir SDK wasn't able to connect to SplitD.
+    # "control" treatment. For example, when feature flag is not found or Elixir SDK wasn't able to connect to Splitd
 end
 ```