@tomerd to look at outstanding PRs
- Where should we home it, apple vs. swift-server —> apple, it will be under github.com/apple, like logging
Vote: Unanimous yes, to sandbox
- Tanner will post a Feedback thread that includes the changes from the Discussion thread
- to be voted on next SSWG meeting
@IanPartridge reduced the size of the official docker images by a lot, the smaller versions will become available with Swift 5.0.1
- Can we have nightlies on docker? We would need a new apple account on Dockerhub because the 'official' repository is for releases only and needs to be authorised by Docker themselves, so we couldn't automatically push a release every night.
@johannesweiss to ask the relevant people if it would be feasible to get a separate Apple account on Dockerhub that CI can push to automatically every night.
- Should we have a slimmed-down runtime image? Ian will post in forums
Other proposals discussions
- Great quality and quantity feedback for Redis
Need: Common API shape for making connections
- Ideally the APIs look & feel similarly and there are things that always need to happen like 'use this
EventLoopGroup' or 'create new ELG'
Need: Connection pooling for all client libs
- Connection pool: @tomerd will seek input from Apple JVM folks that have similar technology on Netty
Version numbers for packages
- SSWG approved packages should tag
1.0.0 even if they are still in 'sandbox' because that works best with SemVer. We can always rev the major version to
2.0.0 if necessary.
- The only meaning attached to
1.0.0 is "we follow SemVer"