From 2d21158cb101843594b8afa8bb16ab5e6338ee94 Mon Sep 17 00:00:00 2001 From: Nghia Luong Date: Tue, 30 May 2023 17:51:30 +0700 Subject: [PATCH 1/2] Add bump version instruction for readme --- README.md | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/README.md b/README.md index 0a8a9f990..f73da8ee7 100644 --- a/README.md +++ b/README.md @@ -57,3 +57,45 @@ Documentation is lacking at the moment, but contributions are welcome! 1. Run `cd Example; bundle exec pod install` 2. Open `Example/KanvasExample.xcworkspace` in Xcode 3. Run the app on a device. + +## Bump version + +### Steps + +1. Open `Kanvas.podspec` +2. Upgrade `spec.version`, please refer `Version naming rules` section below. +3. `cd Example` +4. Run `pod install` +5. `cd ..` and update `CHANGELOG.md` +6. Create a PR from the changes targeting `main` branch + +*You can take [this PR](https://github.com/tumblr/kanvas-ios/pull/151) as an example.* + +### Version naming rules + +(I suggest applying `Semantic Versioning` [technique](https://www.kodeco.com/7076593-cocoapods-tutorial-for-swift-getting-started#toc-anchor-008) from [Kodeco](https://www.kodeco.com/).) + +Many times, you’ll see a version written like this: 1.0.0. Those three numbers are major, minor and patch version numbers. + +For example, for the version number 1.0.0, 1 is the major number, the first 0 is the minor number, and the second 0 is the patch number. + +*Semantic Versioning Example:* **1.2.3**, where: +``` +1: major +2: minor +3: patch +``` + +If the `major` number increases, it indicates that the version contains non-backward-compatible changes. When you upgrade a pod to the next `major` version, you may need to fix build errors or the pod may behave differently than before. + +If the `minor` number increases, it indicates that the version contains new functionality that is backward-compatible. When you decide to upgrade, you may or may not need the new functionality, but it shouldn’t cause any build errors or change existing behavior. + +If the `patch` number increases, it means the new version contains bug fixes but no new functionality or behavior changes. In general, you always want to upgrade `patch` versions as soon as possible to have the latest, stable version of the pod. + +Finally, when you increase the highest-order number — `major`, then `minor` then `patch` — per the above rules, you must reset any lower-order numbers to zero. + +*Here’s an example:* + +Consider a pod that has a current version number of 1.2.3. + +If you make changes that are not backward-compatible, don’t have new functionality, but fix existing bugs, you’d give it version 2.0.0. \ No newline at end of file From f275511cc3ef862589c364b4b9633499d9aa698d Mon Sep 17 00:00:00 2001 From: Nghia Luong Date: Wed, 31 May 2023 14:36:43 +0700 Subject: [PATCH 2/2] Add `semver` as reference of `Version naming rules` --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index f73da8ee7..7e25ffb75 100644 --- a/README.md +++ b/README.md @@ -73,7 +73,7 @@ Documentation is lacking at the moment, but contributions are welcome! ### Version naming rules -(I suggest applying `Semantic Versioning` [technique](https://www.kodeco.com/7076593-cocoapods-tutorial-for-swift-getting-started#toc-anchor-008) from [Kodeco](https://www.kodeco.com/).) +(I suggest applying `Semantic Versioning` [technique](https://www.kodeco.com/7076593-cocoapods-tutorial-for-swift-getting-started#toc-anchor-008) from [Kodeco](https://www.kodeco.com/). Beside, [semver](https://semver.org/) should be worthing checking out.) Many times, you’ll see a version written like this: 1.0.0. Those three numbers are major, minor and patch version numbers.