Correctly bump podspec version

[hassaanelgarem]

This PR only changes the podspec version as it was incorrectly updated in #387

[momo-ozawa]

@hassaanelgarem Sorry for missing this earlier! 😞

JFYI you'll need to publish the new beta version by creating a release on the Releases page (Make sure to set the pre-release check), targeting trunk. (Ref: paNNhX-33-p2)

Btw, I have a question for you @mokagio -- Should we release 1.8.3 on the Releases page? 1.8.3 is the latest stable release but on the Releases page I'm seeing 1.8.0 as the latest non-beta release.

[hassaanelgarem]

@momo-ozawa I was unaware of this process, thanks for the instructions 🙏

[momo-ozawa]

Should we release 1.8.3 on the Releases page? 1.8.3 is the latest stable release but on the Releases page I'm seeing 1.8.0 as the latest non-beta release.

Hey @AliSoftware! 👋
I didn't realize that Gio is AFK -- what do you think about this?

[AliSoftware]

Should we release 1.8.3 on the Releases page? 1.8.3 is the latest stable release but on the Releases page I'm seeing 1.8.0 as the latest non-beta release.

Hey @AliSoftware! 👋 I didn't realize that Gio is AFK -- what do you think about this?

Yes I think it'd be a good idea to publish the missing GitHub Releases for those stable versions (1.8.1, 1.8.2 and 1.8.3), just to be consistent and for good OSS etiquette. 👍

The important technical bit — the one that triggers the push of the pod to CocoaPods' trunk / CDN — is that a tag has been made; but it doesn't hurt to create a GH release as well, especially since that's what act as our CHANGELOG for this pod nowadays (we don't seem to really maintain CHANGELOG.md with fancy details on this repo anymore?).

Personally what I usually do is I go create the GitHub Release directly when I want to release a new version… which creates the git tag for me as a side effect once I publish that GH Release.

[momo-ozawa]

@AliSoftware Thanks for your input! 🙇‍♀️

Yes I think it'd be a good idea to publish the missing GitHub Releases for those stable versions (1.8.1, 1.8.2 and 1.8.3), just to be consistent and for good OSS etiquette. 👍

Sounds good! I'll go ahead and publish 1.8.1, 1.8.2 and 1.8.3 and use the existing tags for these.

Personally what I usually do is I go create the GitHub Release directly when I want to release a new version… which creates the git tag for me as a side effect once I publish that GH Release.

Same! 😄