blob: 3308a2b6c1ac9bc0b34b10b3761454c02f19a5ea [file] [log] [blame]
Tim Petersfc9eeae2000-09-07 08:28:50 +00001Python has a "build number" scheme on Unix-like systems that's hard to
2explain:
3
4Python 2.0b1 (#4, Sep 7 2000, 02:40:55) [MSC 32 bit (Intel)] on win32
5 ^^
6The build number there is "#4".
7
8Each developer's unique build tree generates its own "build numbers",
9starting at 0, and increasing by 1 each time a build is done in that tree.
10These numbers are never checked in, or coordinated in any other way. It's
11just handy for a developer to distinguish among their own personal builds.
12
13The makefile tricks used to accomplish this under Unix-like systems don't
14work under MSDev. Here we fake it by hand, but much less frequently, and
15do check it in. The build number only changes often enough to distinguish
16releases from each other, and from the long "in between" stretches of CVS
17development. An account of all Windows BUILD numbers follows; when you
18check in a new one, please add an entry to the top of the list.
19
20How to change the Windows build number:
21
22+ Right-click on getbuildinfo.c from within MSDev. Select Settings ...
23+ Select the General category of the C/C++ tab.
24+ In "Settings For:" select "Multiple Configurations ...".
25+ Check the "Win32 Release" and "Win32 Debug" boxes and click OK.
26+ In the Preprocessor Definitions box, increment the number after BUILD=.
27+ Click OK.
28+ This is not enough to convince MSDev to recompile getbuildinfo.c,
29 so force that and relink.
30+ Verify that the new build number shows up in both release and debug
31 builds.
32
33
34Windows Python BUILD numbers
35----------------------------
36 5 CVS development
37 07-Sep-2000
38 4 2.0b1 repaired to include Lib\xml + Lib\lib-old + Lib\test\*.xml
39 07-Sep-2000
40 3 2.0b1
41 05-Sep-2000
42 2 CVS development
43 1 unused
44 0 2.0b1p1 and 2.0b1p2
45 01-Sep-2000 for both -- this scheme hadn't started yet