No new releases since Apr 2021 - 1.9.0

[alrocha]

Hi folks!

Why it has no been releases lately? for those who use semantic versions in packages, we can't have the latest fixes unless we point to master, is there any reason behind it?

Thanks

[stephencelis]

Hi @alrocha!

The core of SnapshotTesting is pretty stable and no changes have been staged since 1.9.0. This means the interfaces used to create snapshot strategies and take snapshots are currently in the same state that they are in your project.

Snapshot strategies themselves need a bit more care when cutting releases, and so we need to be careful when doing so. The more volunteers we have to test the main branch, the more quickly we will be able to cut new releases without unintentionally breaking things for everyone.

One thing that would be helpful is some verification from the community that the changes staged on main are non-breaking. If you have projects utilizing SnapshotTesting, would you be interested in contributing some time to verify that they still behave as expected when building from main?

Our goal for SnapshotTesting 2.0.0 is to decouple the core library, which manages the core types and logic around serialization, deserialization, and XCTest integration, with the strategies, like the image strategies and UIKit/SwiftUI strategies, along with some kind of versioning system. This will hopefully remove some of the blockers that prevent releases from happening at a quicker pace right now.

[Jon889]

Sorry to jump in, just wondering how making new versions could unintentionally break things for consumers of the library as they can stay on the older version?

(for context I'm on an M1 while my CI is not, and I'm having to use the fork from this PR #571 so was wondering when it could be released, then realised the last release was in April, which made me reconsider using this library as usually that's an indicator a project isn't maintained anymore)

[stephencelis]

Sorry to jump in, just wondering how making new versions could unintentionally break things for consumers of the library as they can stay on the older version?

The main thing we want to prevent are breaking changes between major releases. Ideally a library consumer can use from: in SPM to safely accept new versions, and this is how most folks configure their Package.swift files. Minor/patch releases should be additive/bugfix releases, so breaking changes from 1.9.0 to 1.10.0 are something we'd like to avoid.

(for context I'm on an M1 while my CI is not, and I'm having to use the fork from this PR #571 so was wondering when it could be released, then realised the last release was in April, which made me reconsider using this library as usually that's an indicator a project isn't maintained anymore)

If you'd like to volunteer some of your time to help test your snapshot artifacts pass on both 1.9.0 and main, you could help us expedite the release 😄

[alrocha]

Hi all!

Same issue as you @Jon889 my temporary fix is add tolerance to the tests until that PR is merged, and a new release is done, but seeing that the last tag will be a year old soon, I need to double check with the team if we could integrate te main branch instead, but probably cloned in our own repo, or fix it to a commit.

Appreciate the quick answer @stephencelis thanks! 😊

[Jon889]

Wouldn’t it be better to do more frequent releases, carefully considering changes to determine if it should be a major/minor version. Then if there are any problems they can be fixed with patch releases. Users can always downgrade to the previous version if necessary and we’ll get fixes for existing problems quicker?

There’s quite a lot of PRs (as great as this project is 😃) so that means there’s probably quite a lot of people waiting for fixes for things and new features. It also means for example we can’t use HEIC and the sub pixel diff at the same time.

I’m using the fork currently so id have to change my test code to be able to use this repo’s version to check if there is anything breaking between main and 1.9.0.

I could probably contribute some views and snapshot tests to this repo, so that breaking changes can be detected here

[XabierGoros]

The core of SnapshotTesting is pretty stable and no changes have been staged since 1.9.0. This means the interfaces used to create snapshot strategies and take snapshots are currently in the same state that they are in your project.

Snapshot strategies themselves need a bit more care when cutting releases, and so we need to be careful when doing so. The more volunteers we have to test the main branch, the more quickly we will be able to cut new releases without unintentionally breaking things for everyone.

I absolutely agree with you @stephencelis, changes have to be tested carefully. It is true though there are some quite interesting PR for the library (I'm another one suffering with the Apple Silicon issue). Perhaps finding a middle way choosing a few PR and creating pre releases tagged versions could work?

Our goal for SnapshotTesting 2.0.0 is to decouple the core library, which manages the core types and logic around serialization, deserialization, and XCTest integration, with the strategies, like the image strategies and UIKit/SwiftUI strategies, along with some kind of versioning system. This will hopefully remove some of the blockers that prevent releases from happening at a quicker pace right now.

That sounds a pretty nice architecture change, which among other things will ease the release flow for sure.

[ugiacoman]

++ to the discussion here.

Our team is also pointing to the fork in #571. If the concern is that there are more untested, pending changes blocking a release, may I suggest you cut a hotfix release that only includes the changes in #571? This will add the functionality that many engineering teams need and also give the community / maintainers enough time to test all the other pending changes.

[simondelphia]

+1 for fixing the M1 issue; we've had to reduce the fuzzy precision and the result is the snapshot tests are missing things.

• Would also like to see a fix for Fix false positive when asserting reference image with empty image #453 / Assign an empty image if a view of zero size is being snapshotted #564 as that's a pretty problematic bug

How can I become a volunteer to help speed things up? Run our snapshots on both 1.9.0 and main and then what? Create issues? Is there a place to post results if there are no issues observed?

[choulepoka]

This topic is of great interest to me personally / professionally, as I am myself running all my projects off main branch because some bug fixes have not been released yet, even though they are a few months old.

[teameh]

The core of SnapshotTesting is pretty stable and no changes have been staged since 1.9.0. This means the interfaces used to create snapshot strategies and take snapshots are currently in the same state that they are in your project.

If would be cool to get #443 released to fix webview snapshots!

[sprejjs]

Hi Team,

I would also like to volunteer to speed things up. This project has been very promising so far, let's not allow it to die, please.

How can I help?

Thanks!

[joliejuly]

Hi guys!

I am suffering from the M1 issue, too.

It's been a year since the latest release. Just a thought - may be you may consider making a minor release with #571 and some other fixes which most likely won't break anything for others but will help tremendously all who is on M1 now?

Thanks!

[teameh]

1.9.0 😱 was released! https://github.com/pointfreeco/swift-snapshot-testing/releases/tag/1.9.0
Thanks @stephencelis 🔥

[teameh]

Haha never mind.. I blame it on the Monday morning... 😅

[simondelphia]

@stephencelis any details on how to volunteer to help speed things up?

[YogeshBhattGWL]

joliejuly

I am too facing issue on Mac M1.
I cant run Test cases.
I am getting error:

Undefined symbols for architecture x86_64:

[stephencelis]

Finally going to close this one out 😅

Be careful with your upgrades! You may need to regenerate and re-audit your snapshots!

https://github.com/pointfreeco/swift-snapshot-testing/releases/tag/1.10.0

[teameh]

Awesome! Thanks for the hard work, much appreciated! 🥳