v2.1.4: Trace IDs can be string-like

Bugfix: If we put a trace ID into the context, but it's not an actual string
(Stringer, subtype of string), we wouldn't fetch it out.

Instead, if the key is present and is string-like, use it.
If it's present and not string-like, add !BADVALUE- and use it.
It's very confusing if the key is ignored entirely when set.

699bd84

Full Changelog: v2.1.3...v2.1.4

v2.1.3: Add logctx.NewLoggerInput.Out field

Allow explicit assignment of the out stream.

c7f3121

Full Changelog: v2.1.2...v2.1.3

Error handling fixes/improvements

Handle 'errors' with 204 and 304 response codes

Programmers can use api.Error with 204 and 304 status codes,
which are not errors per se but still logically valid.

In these cases we must still adhere to the HTTP spec
and return an empty body.

Full Changelog: v2.1.1...v2.1.2

v2.1.1: More logging configuration

What's Changed

• Support more logging configuration by @rgalanakis in #5 and 088b14d

• Add a custom ID provider rather than always using uuid4
• Add a MakeHandler to allow callers to override the
  log handler.
• Add TracingHandler, which provides an easy log handler
  that can log out trace and span ids.
• Allow excluding trace_id from logger attrs,
  for use primarily with TracingHandler
• Allow AfterRequest to return a null logger
  to skip logging.
• The logger passed to the request no longer has
  all the request fields. This is a massive number
  of fields which just spams logs. Instead,
  the trace_id can be used for correllation.

Full Changelog: v2.0.0...v2.1.1

v2.0.0

What's Changed

Bump to version 2. Upgrading should be relatively simple but will require type changes, especially with logging.

Replace logrus with slog. Go 1.21 added the log/slog package to unify structured logging.

Upgrade echo to v4.

Remove some libraries (sqlw, jwtee) which were useful in years past, but patterns have changed and there are alternative ways to do things now.

See #4

Full Changelog: v0.1.4...v2.0.0

v0.1.4: GinkgoV2

Upgrade to GinkgoV2. It is incompatible with GinkgoV1 so causes issues with newer code.

If callers require GinkgoV1, they should use Version 1.0.x.

Add api.Config{App} option, to pass in Echo instance

Add api.Config{App} option, to pass in Echo instance

Full Changelog: v0.1.2...v0.1.3

Customize status and health endpoints

Customize the path and handler of the status endpoint in api.New, and customize the path of the health endpoint (its handler was already customizable).

Allow passing explicit `CORSConfig` to `api.New`

v0.1.1

Allow passing an explicit CORSConfig

Initial Release

We've been using sha-based releases in go.mod files but using actual release versions will allow easier upgrading.

Everything in the v0.1.x will be API-compatible. Any API breakages will be in v0.2.x, though we haven't had any breakages since releasing this library and don't anticipate changing APIs (this code has been in production since 2018).