Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add version bumping instruction for README #158

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Add version bumping instruction for README #158

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2d21158
Add bump version instruction for readme
nghialuong May 30, 2023
f275511
Add `semver` as reference of `Version naming rules`
nghialuong May 31, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 42 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❤️ Nice job including this. Personally I forget this a lot and end up not knowing what's gone wrong 😅

4. Run `pod install`
5. `cd ..` and update `CHANGELOG.md`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔍 Can we add a bit more detail to this step? I believe they have to put any of the unreleased change notes under the current version and check the recent PRs for any merges that have gone in since the last version that haven't made it on to the unreleased section of the change log.

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.*
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
*You can take [this PR](https://github.com/tumblr/kanvas-ios/pull/151) as an example.*
*Reference [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/). Beside, [semver](https://semver.org/) should be worthing checking out.)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's remove the first person here and just state that we're following Semver.

Suggested change
(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.)
We follow the [`Semantic Versioning` (semver) specification](https://semver.org/). You can find more Swift and Cocoapods specific details in [this tutorial](https://www.kodeco.com/7076593-cocoapods-tutorial-for-swift-getting-started#toc-anchor-008).```


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.