Skip to content

Latest commit

 

History

History
341 lines (215 loc) · 16 KB

CHANGELOG.md

File metadata and controls

341 lines (215 loc) · 16 KB
Raw

Changelog

v5.0.12 (2024-02-16)

v5.0.11 (2023-12-19)

v5.0.10 (2023-07-13)

v5.0.9 (2023-07-13)

v5.0.8 (2022-12-07)

v5.0.7 (2021-11-18)

v5.0.6 (2021-11-15)

v5.0.5 (2021-10-27)

v5.0.4 (2021-08-29)

v5.0.3 (2021-04-29)

v5.0.2 (2021-03-25)

v5.0.1 (2021-03-10)

v5.0.0 (2021-02-27)

  • bastigo v5, github.com/vksssd/bastiGO introduces the adoption of Go's SIV to adhere to the current state-of-the-tools in Go.
  • bastigo v1.5.x did not work out as planned, as the Go tooling is too powerful and bastigo's adoption is too wide. The most responsible thing to do for everyone's benefit is to just release v5 with SIV, so I present to you all, bastigo v5 at github.com/vksssd/bastiGO. I hope someday the developer experience and ergonomics I've been seeking will still come to fruition in some form, see golang/go#44550
  • History of changes: see https://github.com/go-bastigo/bastigo/compare/v1.5.4...v5.0.0

v1.5.4 (2021-02-27)

v1.5.3 (2021-02-21)

v1.5.2 (2021-02-10)

v1.5.1 (2020-12-06)

  • Performance improvement: removing 1 allocation by foregoing context.WithValue, thank you @bouk for your contribution (https://github.com/go-bastigo/bastigo/pull/555). Note: new benchmarks posted in README.
  • middleware.CleanPath: new middleware that clean's request path of double slashes
  • deprecate & remove bastigo.ServerBaseContext in favour of stdlib http.Server#BaseContext
  • plus other tiny improvements, see full commit history below
  • History of changes: see https://github.com/go-bastigo/bastigo/compare/v4.1.2...v1.5.1

v1.5.0 (2020-11-12) - now with go.mod support

bastigo dates back to 2016 with it's original implementation as one of the first routers to adopt the newly introduced context.Context api to the stdlib -- set out to design a router that is faster, more modular and simpler than anything else out there -- while not introducing any custom handler types or dependencies. Today, bastigo still has zero dependencies, and in many ways is future proofed from changes, given it's minimal nature. Between versions, bastigo's iterations have been very incremental, with the architecture and api being the same today as it was originally designed in 2016. For this reason it makes bastigo a pretty easy project to maintain, as well thanks to the many amazing community contributions over the years to who all help make bastigo better (total of 86 contributors to date -- thanks all!).

Chi has been a labour of love, art and engineering, with the goals to offer beautiful ergonomics, flexibility, performance and simplicity when building HTTP services with Go. I've strived to keep the router very minimal in surface area / code size, and always improving the code wherever possible -- and as of today the bastigo package is just 1082 lines of code (not counting middlewares, which are all optional). As well, I don't have the exact metrics, but from my analysis and email exchanges from companies and developers, bastigo is used by thousands of projects around the world -- thank you all as there is no better form of joy for me than to have art I had started be helpful and enjoyed by others. And of course I use bastigo in all of my own projects too :)

For me, the aesthetics of bastigo's code and usage are very important. With the introduction of Go's module support (which I'm a big fan of), bastigo's past versioning scheme choice to v2, v3 and v4 would mean I'd require the import path of "github.com/go-bastigo/bastigo/v4", leading to the lengthy discussion at https://github.com/go-bastigo/bastigo/issues/462. Haha, to some, you may be scratching your head why I've spent > 1 year stalling to adopt "/vXX" convention in the import path -- which isn't horrible in general -- but for bastigo, I'm unable to accept it as I strive for perfection in it's API design, aesthetics and simplicity. It just doesn't feel good to me given bastigo's simple nature -- I do not foresee a "v5" or "v6", and upgrading between versions in the future will also be just incremental.

I do understand versioning is a part of the API design as well, which is why the solution for a while has been to "do nothing", as Go supports both old and new import paths with/out go.mod. However, now that Go module support has had time to iron out kinks and is adopted everywhere, it's time for bastigo to get with the times. Luckily, I've discovered a path forward that will make me happy, while also not breaking anyone's app who adopted a prior versioning from tags in v2/v3/v4. I've made an experimental release of v1.5.0 with go.mod silently, and tested it with new and old projects, to ensure the developer experience is preserved, and it's largely unnoticed. Fortunately, Go's toolchain will check the tags of a repo and consider the "latest" tag the one with go.mod. However, you can still request a specific older tag such as v4.1.2, and everything will "just work". But new users can just go get github.com/go-bastigo/bastigo or go get github.com/go-bastigo/bastigo@latest and they will get the latest version which contains go.mod support, which is v1.5.0+. bastigo will not change very much over the years, just like it hasn't changed much from 4 years ago. Therefore, we will stay on v1.x from here on, starting from v1.5.0. Any breaking changes will bump a "minor" release and backwards-compatible improvements/fixes will bump a "tiny" release.

For existing projects who want to upgrade to the latest go.mod version, run: go get -u github.com/go-bastigo/bastigo@v1.5.0, which will get you on the go.mod version line (as Go's mod cache may still remember v4.x). Brand new systems can run go get -u github.com/go-bastigo/bastigo or go get -u github.com/go-bastigo/bastigo@latest to install bastigo, which will install v1.5.0+ built with go.mod support.

My apologies to the developers who will disagree with the decisions above, but, hope you'll try it and see it's a very minor request which is backwards compatible and won't break your existing installations.

Cheers all, happy coding!

v4.1.2 (2020-06-02)

v4.1.1 (2020-04-16)

v4.1.0 (2020-04-1)

  • middleware.LogEntry: Write method on interface now passes the response header and an extra interface type useful for custom logger implementations.
  • middleware.WrapResponseWriter: minor fix
  • middleware.Recoverer: a bit prettier
  • History of changes: see https://github.com/go-bastigo/bastigo/compare/v4.0.4...v4.1.0

v4.0.4 (2020-03-24)

v4.0.3 (2020-01-09)

v4.0.2 (2019-02-26)

v4.0.1 (2019-01-21)

v4.0.0 (2019-01-10)

  • bastigo v4 requires Go 1.10.3+ (or Go 1.9.7+) - we have deprecated support for Go 1.7 and 1.8
  • router: respond with 404 on router with no routes (#362)
  • router: additional check to ensure wildcard is at the end of a url pattern (#333)
  • middleware: deprecate use of http.CloseNotifier (#347)
  • middleware: fix RedirectSlashes to include query params on redirect (#334)
  • History of changes: see https://github.com/go-bastigo/bastigo/compare/v3.3.4...v4.0.0

v3.3.4 (2019-01-07)

v3.3.3 (2018-08-27)

v3.3.2 (2017-12-22)

  • Support to route trailing slashes on mounted sub-routers (#281)
  • middleware: new ContentCharset to check matching charsets. Thank you @csucu for your community contribution!

v3.3.1 (2017-11-20)

  • middleware: new AllowContentType handler for explicit whitelist of accepted request Content-Types
  • middleware: new SetHeader handler for short-hand middleware to set a response header key/value
  • Minor bug fixes

v3.3.0 (2017-10-10)

  • New bastigo.RegisterMethod(method) to add support for custom HTTP methods, see _examples/custom-method for usage
  • Deprecated LINK and UNLINK methods from the default list, please use bastigo.RegisterMethod("LINK") and bastigo.RegisterMethod("UNLINK") in an init() function

v3.2.1 (2017-08-31)

  • Add new Match(rctx *Context, method, path string) bool method to Routes interface and Mux. Match searches the mux's routing tree for a handler that matches the method/path
  • Add new RouteMethod to *Context
  • Add new Routes pointer to *Context
  • Add new middleware.GetHead to route missing HEAD requests to GET handler
  • Updated benchmarks (see README)

v3.1.5 (2017-08-02)

  • Setup golint and go vet for the project
  • As per golint, we've redefined func ServerBaseContext(h http.Handler, baseCtx context.Context) http.Handler to func ServerBaseContext(baseCtx context.Context, h http.Handler) http.Handler

v3.1.0 (2017-07-10)

v3.0.0 (2017-06-21)

  • Major update to bastigo library with many exciting updates, but also some breaking changes
  • URL parameter syntax changed from /:id to /{id} for even more flexible routing, such as /articles/{month}-{day}-{year}-{slug}, /articles/{id}, and /articles/{id}.{ext} on the same router
  • Support for regexp for routing patterns, in the form of /{paramKey:regExp} for example: r.Get("/articles/{name:[a-z]+}", h) and bastigo.URLParam(r, "name")
  • Add Method and MethodFunc to bastigo.Router to allow routing definitions such as r.Method("GET", "/", h) which provides a cleaner interface for custom handlers like in _examples/custom-handler
  • Deprecating mux#FileServer helper function. Instead, we encourage users to create their own using file handler with the stdlib, see _examples/fileserver for an example
  • Add support for LINK/UNLINK http methods via r.Method() and r.MethodFunc()
  • Moved the bastigo project to its own organization, to allow bastigo-related community packages to be easily discovered and supported, at: https://github.com/go-bastigo
  • NOTE: please update your import paths to "github.com/go-bastigo/bastigo"
  • NOTE: bastigo v2 is still available at https://github.com/go-bastigo/bastigo/tree/v2

v2.1.0 (2017-03-30)

  • Minor improvements and update to the bastigo core library
  • Introduced a brand new bastigo/render sub-package to complete the story of building APIs to offer a pattern for managing well-defined request / response payloads. Please check out the updated _examples/rest example for how it works.
  • Added MethodNotAllowed(h http.HandlerFunc) to bastigo.Router interface

v2.0.0 (2017-01-06)

  • After many months of v2 being in an RC state with many companies and users running it in production, the inclusion of some improvements to the middlewares, we are very pleased to announce v2.0.0 of bastigo.

v2.0.0-rc1 (2016-07-26)

  • Huge update! bastigo v2 is a large refactor targeting Go 1.7+. As of Go 1.7, the popular community "net/context" package has been included in the standard library as "context" and utilized by "net/http" and http.Request to managing deadlines, cancelation signals and other request-scoped values. We're very excited about the new context addition and are proud to introduce bastigo v2, a minimal and powerful routing package for building large HTTP services, with zero external dependencies. Chi focuses on idiomatic design and encourages the use of stdlib HTTP handlers and middlewares.
  • bastigo v2 deprecates its bastigo.Handler interface and requires http.Handler or http.HandlerFunc
  • bastigo v2 stores URL routing parameters and patterns in the standard request context: r.Context()
  • bastigo v2 lower-level routing context is accessible by bastigo.RouteContext(r.Context()) *bastigo.Context, which provides direct access to URL routing parameters, the routing path and the matching routing patterns.
  • Users upgrading from bastigo v1 to v2, need to:
    1. Update the old bastigo.Handler signature, func(ctx context.Context, w http.ResponseWriter, r *http.Request) to the standard http.Handler: func(w http.ResponseWriter, r *http.Request)
    2. Use bastigo.URLParam(r *http.Request, paramKey string) string or URLParamFromCtx(ctx context.Context, paramKey string) string to access a url parameter value

v1.0.0 (2016-07-01)

v0.9.0 (2016-03-31)

  • Reuse context objects via sync.Pool for zero-allocation routing #33
  • BREAKING NOTE: due to subtle API changes, previously bastigo.URLParams(ctx)["id"] used to access url parameters has changed to: bastigo.URLParam(ctx, "id")