2 Notes on doing a release
5 - Have ChangeLog kept updated during development
6 - Also NEWS, THANKS, README and the doc/UrJTAG.txt
7 - Plus ../web/htdocs/index.html section 'Status'
8 So far the continues effort
11 - Have or create awareness there is an upcoming release
12 - Version number is formatted as YYYY.MM
14 - Update the version in configure.ac
15 - Put the same version number in NEWS
17 - make dist-xz # updates .po files
19 - git commit -m 'po/*.po timestamps due `./autogen.sh`'
21 - Various `git add` on where needed
22 - Another `git commit`
27 - Some checksumming and signing
28 ( there is tools/checksumming )
29 - Upload the .tar.xz and checksums to SoureForce
30 See https://sourceforge.net/p/forge/documentation/Files/ how
31 - update, build and commit web content, clue: ../web/Makefile
34 > If there are already some notes on doing a release,
35 > then please tell the mailinglist(archive) about it.
39 work to do that already kept me from "simply releasing" a few times
40 because it takes a bit of time and diligence:
45 - (TBD) build binaries for download, especially for windows..
47 Do NOT make any last-minute functional/build/code changes. Just touch
48 documentation for the release.
50 The only overall change that I find worth considering at this moment
51 is maybe to separate all the handcrafted or compiled chip data
52 (urjtag/data content) from the actual UrJTAG code. Especially with the
53 "new" ability to read BSDL directly, the data/ lost its importance
54 somewhat. This question might be discussed especially by the
55 maintainers of urjtag packages for distribution?
57 Nb the "urjtag.com" and "urjtag.de" domain registration only lives
58 until the end of this year, but I'll continue to support
59 "urjtag.org". If the project is not moved somewhere else where there
60 is no webserver for the www. A record, as it is now configured with
61 sourceforge.. well, anyway, that is certainly not life-critical for