Should 2.39.1 enough to generate mocks for 2.40.1 about mockery HOT 7 CLOSED

It was introduced in 2.40.0 so you'd need to upgrade to that.

from mockery.

bash -x ./vendor.sh mockery-2.40.0.tar.gz 
+ set -e
+ ARCHIVE=mockery-2.40.0.tar.gz
+ DIRNAME=mockery-2.40.0
+ '[' -d mockery-2.40.0 ']'
+ tar xf mockery-2.40.0.tar.gz
+ cd mockery-2.40.0
+ mockery --config .mockery.yaml
19 Jan 24 15:57 CET INF Starting mockery dry-run=false version=2.39.1
19 Jan 24 15:57 CET INF Using config: .mockery.yaml dry-run=false version=2.39.1
failed to discover recursive packages: failed to get package config: 1 error(s) decoding:

* '' has invalid keys: mock-build-tags

you can not even bootstrap the new release with release-1? that feels like a bit harsh.

from mockery.

Would it be possible maybe to provide tarballs with the mocks already generated?

from mockery.

Your logs indicate you're running the wrong version.

How is mockery supposed to provide a feature in 2.39.1 that did not exist at the time? Bumping the minor version to get new features is consistent with semver. Not sure how that's harsh.

from mockery.

Would it be possible maybe to provide tarballs with the mocks already generated?

I don't understand the question. Can you elaborate?

from mockery.

well I want to upgrade to 2.40.0 as a packager the only version i currently have is 2.39.1. which is literally the realease before. so you have zero grace period. the only way to be able to upgrade is using prebuilt binaries from github to generate the new mocks. which most packagers try to avoid. IMHO it is a good policy to ensure that a new release can be built with the previous release so there is an upgrade path.

so 2.40.0 should be buildable with 2.39.1 and 2.40.1 can require 2.40.0.

hence my question can you provide a tarball as part of your release process which includes those files which mockery would generate?

from mockery.

so 2.40.0 should be buildable with 2.39.1 and 2.40.1 can require 2.40.0.

I still don't understand this comment. Introducing a new feature in a debug release is not appropriate semver.

the only way to be able to upgrade is using prebuilt binaries from github to generate the new mocks. which most packagers try to avoid.

I mean yes, if you want to use a new feature, you need to download the new minor release. That is how semver works.

If your complaint is that something broke such that backwards compatibility was violated, that is a totally different question. But the assertion that a new feature should have been added in a debug release is not valid because it violates semver. I have never had anyone make this kind of complaint before in all my time managing large public projects.

from mockery.