10000 README: fix list formatting · drinkingjava/python-versioneer@0bb4f04 · GitHub
[go: up one dir, main page]
Skip to content

Commit 0bb4f04

Browse files
warnerwarner
committed
README: fix list formatting
1 parent a13b40e commit 0bb4f04

File tree

2 files changed

+28
-28
lines changed

2 files changed

+28
-28
lines changed

‎README.md

Lines changed: 14 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -116,30 +116,30 @@ This tool provides one script, named `versioneer.py`.
116116

117117
To versioneer-enable your project:
118118

119-
1: copy `versioneer.py` into the top of your source tree
119+
* 1: copy `versioneer.py` into the top of your source tree
120120

121-
2: add the following lines to the top of your `setup.py`, with suitable
122-
values for each configuration setting:
121+
* 2: add the following lines to the top of your `setup.py`, with suitable
122+
values for each configuration setting:
123123

124124
import versioneer
125125
versioneer.versionfile_source = 'src/myproject/_version.py'
126126
versioneer.versionfile_build = 'myproject/_version.py'
127127
versioneer.tag_prefix = '' # tags are like 1.2.0
128128
versioneer.parentdir_prefix = 'myproject-' # dirname like 'myproject-1.2.0'
129129

130-
3: add the following arguments to the setup() call in your setup.py:
130+
* 3: add the following arguments to the setup() call in your setup.py:
131131

132132
version=versioneer.get_version(),
133133
cmdclass=versioneer.get_cmdclass(),
134134

135-
4: run `setup.py update_files`, which will create `_version.py`, and will
136-
modify your `__init__.py` to define `__version__` (by calling a function
137-
from `_version.py`)
135+
* 4: run `setup.py update_files`, which will create `_version.py`, and will
136+
modify your `__init__.py` to define `__version__` (by calling a function
137+
from `_version.py`)
138138

139-
5: modify your MANIFEST.in to include `versioneer.py` in sdist tarballs
139+
* 5: modify your MANIFEST.in to include `versioneer.py` in sdist tarballs
140140

141-
6: commit these changes to your VCS. `update_files` will mark both
142-
`versioneer.py` and the generated `_version.py` for addition.
141+
* 6: commit these changes to your VCS. `update_files` will mark both
142+
`versioneer.py` and the generated `_version.py` for addition.
143143

144144
## Post-Installation Usage
145145

@@ -150,14 +150,14 @@ version string (so users who unpack them will not need a VCS tool installed).
150150
If you distribute your project through PyPI, then the release process should
151151
boil down to two steps:
152152

153-
1: git tag 1.0
154-
2: python setup.py register sdist upload
153+
* 1: git tag 1.0
154+
* 2: python setup.py register sdist upload
155155

156156
If you distribute it through github (i.e. users use github to generate
157157
tarballs with `git archive`), the process is:
158158

159-
1: git tag 1.0
160-
2: git push; git push --tags
159+
* 1: git tag 1.0
160+
* 2: git push; git push --tags
161161

162162
Currently, all version strings must be based upon a tag. Versioneer will
163163
report "unknown" until your tree has at least one tag in its history. This

‎versioneer.py

Lines changed: 14 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -120,30 +120,30 @@
120120
121121
To versioneer-enable your project:
122122
123-
1: copy `versioneer.py` into the top of your source tree
123+
* 1: copy `versioneer.py` into the top of your source tree
124124
125-
2: add the following lines to the top of your `setup.py`, with suitable
126-
values for each configuration setting:
125+
* 2: add the following lines to the top of your `setup.py`, with suitable
126+
values for each configuration setting:
127127
128128
import versioneer
129129
versioneer.versionfile_source = 'src/myproject/_version.py'
130130
versioneer.versionfile_build = 'myproject/_version.py'
131131
versioneer.tag_prefix = '' # tags are like 1.2.0
132132
versioneer.parentdir_prefix = 'myproject-' # dirname like 'myproject-1.2.0'
133133
134-
3: add the following arguments to the setup() call in your setup.py:
134+
* 3: add the following arguments to the setup() call in your setup.py:
135135
136136
version=versioneer.get_version(),
137137
cmdclass=versioneer.get_cmdclass(),
138138
139-
4: run `setup.py update_files`, which will create `_version.py`, and will
140-
modify your `__init__.py` to define `__version__` (by calling a function
141-
from `_version.py`)
139+
* 4: run `setup.py update_files`, which will create `_version.py`, and will
140+
modify your `__init__.py` to define `__version__` (by calling a function
141+
from `_version.py`)
142142
143-
5: modify your MANIFEST.in to include `versioneer.py` in sdist tarballs
143+
* 5: modify your MANIFEST.in to include `versioneer.py` in sdist tarballs
144144
145-
6: commit these changes to your VCS. `update_files` will mark both
146-
`versioneer.py` and the generated `_version.py` for addition.
145+
* 6: commit these changes to your VCS. `update_files` will mark both
146+
`versioneer.py` and the generated `_version.py` for addition.
147147
148148
## Post-Installation Usage
149149
@@ -154,14 +154,14 @@
154154
If you distribute your project through PyPI, then the release process should
155155
boil down to two steps:
156156
157-
1: git tag 1.0
158-
2: python setup.py register sdist upload
157+
* 1: git tag 1.0
158+
* 2: python setup.py register sdist upload
159159
160160
If you distribute it through github (i.e. users use github to generate
161161
tarballs with `git archive`), the process is:
162162
163-
1: git tag 1.0
164-
2: git push; git push --tags
163+
* 1: git tag 1.0
164+
* 2: git push; git push --tags
165165
166166
Currently, all version strings must be based upon a tag. Versioneer will
167167
report "unknown" until your tree has at least one tag in its history. This

0 commit comments

Comments
 (0)
0