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