search

wordpress-mobile / MediaPicker-iOS

WPMediaPicker is an iOS controller that allows capture and picking of media assets.
GNU General Public License v2.0
110 stars 37 forks source link

Correctly bump podspec version #388

Closed hassaanelgarem closed 2 years ago

hassaanelgarem commented 2 years ago

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

hassaanelgarem commented 2 years ago

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

momo-ozawa commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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! 😄