Open hugo-vrijswijk opened 11 months ago
I agree that it's best to minimize necessary code changes. But on the other hand, when's a good time to introduce them, if not in a major release? I'm not so sure about adding deprecated members in a major release, which will have to essentially stay there forever (unless we do a sttp 5 ;) )
(that said, I'm open for other voices for the community, if this indeed would be important to a larger group of people, let's introduce the deprecated members)
The structured logging from #1938 is very cool. But it also introduces a breaking change with the extra context parameters compared to
sttp.client3
, which does not have thecontext
. This is a breaking change for anyone implementing their own logger (which is pretty common for wrapping sttp logging into your own logger). IMO, migrating from sttp 3 to 4 should be as easy as possible, so I think it would be a good idea to avoid source-breaking without good reason.Some options, maybe:
apply
with the 'old' signature, deprecate it (potentially) and give it a default implementation of callingapply
with empty context. This way, users can choose when to migrate to using context for the loggersttp.client4.logging.Logger
to the contextless logger. The type alias could be deprecated. But it could be beneficial to keep as a 'simple' logger for implementations that don't have the concept of contextBaseLogger
and aContextlessLogger
/StructuredLogger
extends BaseLogger