|
45 | 45 | "To put yourself in a clean state again, you have to:\n",
|
46 | 46 | "\n",
|
47 | 47 | "1. Click \"remove branch\" in the pull request (don't click \"remove fork\"!)\n",
|
48 |
| - "2. `git checkout master` to go back to `master`\n", |
| 48 | + "2. `git checkout master` (go back to `master`)\n", |
49 | 49 | "3. `git fetch origin` (**never, ever use `git pull` unless you know exactly what you're doing**)\n",
|
50 |
| - "4. `git merge --ff-only origin master` (this will update your local `master` with `origin/master`, and fail if you accidentally made any commit in `master`)\n", |
51 |
| - "5. `git fetch -p <username>` :star2: this will acknowledge the removal of the branch :star2:\n", |
52 |
| - "6. `git push <username> master` (this will update your fork with respect to `origin`)\n", |
53 |
| - "7. `git checkout -b new-branch` to start working in the new feature!\n", |
| 50 | + "4. `git merge --ff-only origin master` (update your local `master` with `origin/master`, and fail if you accidentally made any commit in `master`)\n", |
| 51 | + "5. `git fetch -p <username>` (✨ acknowledge the removal of the remote branch ✨)\n", |
| 52 | + "6. `git branch -d old-branch` (remove the old branch)\n", |
| 53 | + "7. `git push <username> master` (update your fork with respect to `origin`)\n", |
| 54 | + "8. `git checkout -b new-branch` (start working in the new feature!)\n", |
54 | 55 | "\n",
|
55 | 56 | "This process **has to be repeated after every pull request**.\n",
|
56 | 57 | "\n",
|
|
114 | 115 | "```\n",
|
115 | 116 | "[metadata]\n",
|
116 | 117 | "name = my_package\n",
|
117 |
| - "version = 0.1.0\n", |
| 118 | + "version = 0.1.dev0\n", |
118 | 119 | "\n",
|
119 | 120 | "# Magic! Don't touch below this line\n",
|
120 | 121 | "[options]\n",
|
|
140 | 141 | "This is an alternative to modifying the `PYTHONPATH` environment variable (see first session)."
|
141 | 142 | ]
|
142 | 143 | },
|
| 144 | + { |
| 145 | + "cell_type": "markdown", |
| 146 | + "metadata": {}, |
| 147 | + "source": [ |
| 148 | + "### Version numbers\n", |
| 149 | + "\n", |
| 150 | + "* Version numbers for Python packages are explained in [PEP 440](https://www.python.org/dev/peps/pep-0440/)\n", |
| 151 | + "* For libraries, the most widely used convention is [semantic versioning](https://semver.org/): `X.Y.Z`\n", |
| 152 | + " - `Z` **must** be incremented if only backwards compatible bug fixes are introduced (a bug fix is defined as an internal change that fixes incorrect behavior)\n", |
| 153 | + " - `Y` **must** be incremented every time there is new, backwards-compatible functionality\n", |
| 154 | + " - `X` **must** be incremented every time there are backwards-incompatible changes\n", |
| 155 | + "* Between releases, the version should have the `.dev0` suffix\n", |
| 156 | + "* Recommendation: start with `0.1.dev0` (development version), then make a `0.1.0` release, then progress to `0.1.1` for quick fixes and `0.2.0` for new functionality, and when you want to make a promise of *relative* stability jump to `1.0.0`\n", |
| 157 | + "* For applications, other conventions are more appropriate, like [calendar versioning](http://calver.org/): `[YY]YY.MM.??" |
| 158 | + ] |
| 159 | + }, |
143 | 160 | {
|
144 | 161 | "cell_type": "markdown",
|
145 | 162 | "metadata": {},
|
|
0 commit comments