## Motivation
RediStack 1.x is going to be supported at least until 2.x is released, which is a few months away.
Developers who are on later versions of Swift will adopt later versions of NIO and other libraries, and after we merged !183 we required NIO 2.42.x which has a minimum Swift version of 5.5
## Changes
This back ports the CI config from `master` into this branch, with updates to the README to reflect the changes
Motivation:
Redis is written in C, so even though it has concepts of "types" such as SortedSet or List
its commands are all "free-floating" functions.
This can make it unfamiliar for those new to Redis to work within its systems and understand the relation of all of the commands.
RediStack can improve this by giving a way of having a consistent reference to a Redis type and all of its associated methods.
Modifications:
- Add: New library product called "RedisTypes"
- Add: First type to "RedisTypes", `RedisSet`
Result:
Newcomers to Redis will have an easier time getting familiar with the APIs and working with its types by having wrappers that
provide a familiar Swift Standard Library API tailored to Redis APIs.
Motivation:
SwiftPM as of Swift 5.2 introduces a new package dependency graph and package description that makes the current naming of RediStack awkward to pull in.
Modifications:
- Change: Package.name to be "RediStack"
The git repo will be renamed to "mordil/redistack" in addition to this change.
Result:
Fixes#72 and makes it seamless to pull in RediStack as a Swift package dependency.
Motivation:
For users looking to contribute, and for those looking to validate the library, it was unclear what tests require an actual connection to a Redis instance in order to run.
Modifications:
Add a `RediStackIntegrationTests` that takes all tests that require a Redis instance in order to run.
Result:
Those looking to run just unit tests, or contribute new tests, can now directly point to a specific testTarget as defined in the Package manifest.
Motivation:
Johannes provided a fair code review of the project and summarized his findings in issue #48, and one of the prime offenders was all of the `unsafe*` APIs (pointers, buffers, bytes)
that were used with `RESPValue` and `RESPValueConvertible`.
He also provided great feedback and pointed out good points of confusion with the API design of `RESPValue` and `RESPValueConvertible`.
Modifications:
- Return to using `Array` instead of `ContiguousArray` for `RESPValue.array` storage
- Update all documentation to be more thorough in explaining how the types should be used and conformed to.
- Remove all uses of `unsafe*` APIs where possible
- Change implementations to be a lot more type and memory safe, double checking assumptions
- Remove conformance to `ExpressibleBy*Literal` as it is too easy for users to shoot themselves in the foot and saves only a few characters over `.init(bulk:)`
- Create new `RedisNIOTestUtils` target for common test extensions, making them public
- Move most almost all implementations of `RESPValue` computed properties into the `RESPValueConvertible` conformances
Result:
Users should be more safeguarded by the API against unknowingly getting incorrect `RESPValue` representations, the API design of `RESPValue` and `RESPValueConvertible` should be much clearer,
and memory safety should be at a higher bar from these changes.
This resolves issues #55 & #48, and contributes to issue #47.
Motivation:
The SSWG has identified a fast approaching reality of namespace clashes in SPM within the ecosystem and has proposed a rule on names that `NIORedis` no longer complies with.
Modifications:
All references to `NIORedis` have been switched to `RedisNIO` as this module name is unique (at least within GitHub's public repositories).
The goals for this name are as follows:
1. To indicate that this is a Redis client library that is built with SwiftNIO
2. That it is a lower level library, as it directly exposes SwiftNIO as an implementation detail
2a. The idea being that a higher level library (`Redis`) will be used, and to "go one level deeper" in the stack, you append the "deeper" `NIO` postfix
3. It follows a naming pattern adopted by Vapor who has expressed their desire to adopt this library as their Redis implementation
Result:
A repository, package name, and module name that are unique across GitHub's public repositories that achives the goals outlined above.
Nathan Harris
Fabian Fett
Nathan Harris
Nathan Harris