mokagio
commented
1 year ago I wouldn't generalize this behavior [making out-of-cycle releases] to all the first-level internal libs though, as I think once we'll be well into the new model and stop creating betas and have everyone point to trunk sha1s during development, it would probably make sense to only tag new versions when clients ship a new version of the apps.
Yep 👍
TL;DR I'd like to ship a new release of this library. Normally, I'd just ship it, but I'd like to run it past you because we're in a phase of transition in how we manage internal Apple libraries and I don't want to generate confusion.
So far and in the context of release management I haven't been requesting reviews in PRs for library releases because it seems to me like unnecessary ceremony. The only code that's reviewed is the version bump, and while it's true that there is room for error in that, too, in the context of libraries meant for internal shipping a build with the wrong version ever once in a while is worth not having to wait for a review every time. IMHO.
But this is a release outside the usual apps release cycle and in a time of migration from the model of using betas to ship changes to using
trunkduring development. So, I'm asking for a review because I want to run past you the idea of making a new release outside the usual cycle, that is, without a code freeze starting at the same time.The reason I want to do a new release is to use
ConsoleLogger, #335, in the demo app for WordPress Authenticator. I am already usingConsoleLoggerviatrunkin there and verified it works.I didn't opt for a beta because we are actively trying to move away from them in the client apps.
What do you think? Is it appropriate to ship a new build at this time to distribute a new feature to a downstream dependency?
I think it is. Client apps can point to
trunkduring development, but client libraries should always point to shipped versions of their dependencies.CHANGELOG.mdif necessary.