Releases: pressly/goose
v2.7.0-rc2 Add vendor/ directory; Fix bunch of issues
v2.7.0-rc1 Refactor SQL parser
Refactors SQL parser pretty much from scratch, adds a super simple state machine parser, to fix bunch of reported issues:
Fixes #87
Fixes #132
Fixes #122
Fixes #138
We have tested this release against our pre-production environments and against a test suite of ~100 .sql and ~50 .go migrations. The above issues look to be fixed; at least from the unit test perspective.
Please, help us test this release against your migration files on pre-production environments to ensure this release candidate is in a good shape and has no regressions!
v2.6.0 Improve error handling, --version & -v flags
- Improve error handling
- use errors.Wrap() and propagate error context, ie. print SQL statement that caused the rollback
- add missing error checks
- remove log.Fatal() calls from the goose pkg - everything returns error and can be used as import library
- Add --version flag to print current version of the binary
- Add -v flag for "verbose" mode - for debugging purposes
- Don't create goose_db_table on
goose status
v2.5.0 - fix large .sql migrations; use default std logger
Remove unused update queries
Merge pull request #133 from pressly/fix_dialect Remove unused update query
down command now removes version row record
This will resolve dangling records when deploying different version codebases to the same DB
Fix missing return statement for fix command
Merge pull request #126 from pressly/add-fix-return add return here
Fix panic when goose is ran without any arguments
Thanks to @jstrohm-triller for catching this regression
Build tags to exclude drivers
We now support build tags to exclude DB drivers such as no_mysql
, no_sqlite
, and no_psql
. This will provide users with the flexibility to exclude drivers they don't need. This design will still include all drivers by default for ease of use.
Hybrid migration versioning
We came up with a solution to the versioning problem.
Hybrid Versioning
We strongly recommend adopting a hybrid versioning approach, using both timestamps and sequential numbers. Migrations created during the development process are timestamped and sequential versions are ran on production. We believe this method will prevent the problem of conflicting versions when writing software in a team environment.
To help you adopt this approach, create
will use the current timestamp as the migration version. When you're ready to deploy your migrations in a production environment, we also provide a helpful fix
command to convert your migrations into sequential order, while preserving the timestamp ordering. We recommend running fix
in the CI pipeline, and only when the migrations are ready for production.