1
1
pygame.org website |build-status | |coverage-status |
2
2
===================================================
3
3
4
- Pieces of the pygame website will be open sourced here.
4
+ Pieces of the pygame website (https://www.pygame.org/) will be open sourced here.
5
5
6
6
Strategy is to bring in code one piece at a time, and clean it up as I go.
7
7
8
8
9
+ It's a community website where people can post projects, comment on them,
10
+ but also write things in there themselves on wiki pages.
11
+
12
+
9
13
Contributing
10
14
============
11
15
@@ -233,14 +237,16 @@ With with a @cache decorator, and/or markup in a template.
233
237
Releases
234
238
========
235
239
236
- Releases are done from travisci. Fairly closely following this:
237
- https://docs.travis-ci.com/user/deployment/pypi/
240
+ Step by step release instructions below.
238
241
239
242
- Commits to `master ` branch do a dev deploy to pypi.
240
243
- Commits to `mastertest ` branch do a dev deploy to pypi.
241
244
- Commits to a tag do a real deploy to pypi.
242
245
243
246
247
+ Prereleases
248
+ -----------
249
+
244
250
https://packaging.python.org/tutorials/distributing-packages/#pre-release-versioning
245
251
246
252
Pre releases should be named like this:
@@ -252,8 +258,52 @@ Which is one version ahead of of the last tagged release.
252
258
253
259
Release tags should be like '0.0.2', and match the `pygameweb/__init__.py __version__ `.
254
260
255
- When everything is ready, tags should be done through github.
256
261
257
- Note: do not tag pre releases (these are made on commits to `master `/`mastertest `).
262
+ Preparing a release in a branch.
263
+ --------------------------------
264
+
265
+ It's a good idea to start a branch first, and make any necessary changes
266
+ for the release.
267
+
268
+ ```
269
+ git checkout -b v0.0.2
270
+ vi pygameweb/__init__.py __version__ = '0.0.2'
271
+ git commit -m "Version 0.0.2"
272
+ ```
273
+
274
+ Change log, drafting a release.
275
+ -------------------------------
276
+
277
+ Github 'releases' are done as well.
278
+ You can start drafting the release notes in there before the tag.
258
279
https://help.github.com/articles/creating-releases/
259
280
281
+ You can make the release notes with the help of the changes since last release.
282
+ https://github.com/pygame/pygameweb/compare/0.0.1...master
283
+
284
+ git log 0.0.1...master
285
+
286
+ Tagging a release
287
+ -----------------
288
+
289
+ When the release is tagged, pushing it starts the deploy to pypi off.
290
+ ```
291
+ git tag -a 0.0.2
292
+ git push origin 0.0.2
293
+ ```
294
+ Note: do not tag pre releases
295
+ (these are made on commits to `master `/`mastertest `).
296
+
297
+ After the tag is pushed, then you can do the release
298
+ in github from your draft release.
299
+
300
+
301
+ Back to dev version.
302
+ --------------------
303
+
304
+ If we were at 0.0.2 before, now we want to be at 0.0.3.dev
305
+ ```
306
+ vi pygameweb/__init__.py __version__ = '0.0.3.dev'
307
+ ```
308
+
309
+ Merge the release branch into master, and push that up.
0 commit comments