ZY

@jenil163 Are you able to share how `migrate.NewWIthDatabaseInstance` is called and what version of migrate you're using?

@esalter I think the images are indeed [properly tagged](https://hub.docker.com/r/edoburu/pgbouncer/tags) using semver, and you should still be getting `1.14.0` if you pulled `edoburu/pgbouncer:1.14.0`. EDIT: See #35 for proposal for immutable tags

@grizim-power Ordinarily, yes, but not feasible for a project like `edoburu/docker-pgbouncer` that provides container images to a corresponding `pgbouncer` release. Take the current release for example; if it is buggy...

@grizim-power Yeah, completely agree, image tags should be immutable.

@jflambert Thanks for looking into this! Although I no longer work with `docker-pgbouncer`, I think many others would appreciate the work done to improve the existing tags. The format you...

I think it may be reasonable for `IgnoreUnexported` to be the default behaviour only if there is a way to signal to the user that unexported fields are not checked....

Thanks @claudioscalzo, I have updated the issue to reflect the GA status.

@ScottSuarez I can't speak for everyone but maybe I can share my use case when I first created this issue. In our organisation, we use Terraform to manage resources on...

I just encountered this after upgrading from `0.15.0` to `1.0.0`. Interestingly, **no changes were proposed** even when Terraform detected a drift on the `etag` field: ```console $ terraform plan Acquiring...

I think that the `etag` field is not particularly useful **to end-users**, so implementing [`DiffSuppressFunc`](https://pkg.go.dev/github.com/hashicorp/terraform-plugin-sdk/helper/schema?utm_source=gopls#Schema.DiffSuppressFunc) should be a good approach to workaround this issue. Suppressing the `etag` field should not...