matryer
commented
8 years ago We could add a warning to v1 code that says: “Testify 2 is out now, upgrade: LINK TO DOC”.
We might be able to write a simple tool that vets v1 code and judges it’s readiness for v2? Although, the order of arguments is a tough one to vet.
Since Stretchr is no more, I wonder if we should start v2 in https://github.com/gotestify https://github.com/gotestify ?
Mat
On 12 May 2016, at 11:14, Ernesto Jiménez notifications@github.com wrote:
There's a good deal of issues related to inconsistencies (e.g: argument ordering in assert) and confusing configuration (e.g: mock.Times(0) meaning any number of times).
Fixing those would require releasing a new version of testify with breaking changes. However, since Go has no concept of versioning, we would need to release new import paths for testify.
Since there are so many packages depending on testify, the following questions would need to be answered first:
How will users know a new testify version has been released? What percentage of projects would upgrade? What percentage of new projects would use the latest version? Will we fix bugs from our current import path or abandon all the users in the current version? How can we facilitate the upgrade process? The best OS project I've seen managing versions and breaking changes is Ember. With releases every six weeks, zero breaking changes within big version numbers, clear deprecation warnings for features that will break or disappear in the next big version, and feature flags to opt in to behaviours that will be the default in future versions.
The second part of Ember's promise is that, once they release a new major version (e.g: 2.0), an app using the last minor previous version (e.g: 1.25) with zero warnings can simply point their app to the new version and the app will run.
Are there any Go packages doing anything remotely similar?
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/stretchr/testify/issues/306
ernesto-jimenez
yamikuronue
There's a good deal of issues related to inconsistencies (e.g: argument ordering in
assert) and confusing configuration (e.g:mock.Times(0)meaning any number of times).Fixing those would require releasing a new version of testify with breaking changes. However, since Go has no concept of versioning, we would need to release new import paths for testify.
Since there are so many packages depending on testify, the following questions would need to be answered first:
The best OS project I've seen managing versions and breaking changes is Ember. With releases every six weeks, zero breaking changes within big version numbers, clear deprecation warnings for features that will break or disappear in the next big version, and feature flags to opt in to behaviours that will be the default in future versions.
The second part of Ember's promise is that, once they release a new major version (e.g: 2.0), an app using the last minor previous version (e.g: 1.25) with zero warnings can simply point their app to the new version and the app will run.
Are there any Go packages doing anything remotely similar?