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
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
|
Dear Gyoto developers,
A few notes on maintenance:
Before each commit:
===================
* If you touched configure.ac or any Makefile.am file, run autoreconf
and commit the regenerated files (configure, Makefile*.in)
* Run make check. If possible, build the yorick plug-in so that
make-check will do the detailed regression testing suite.
* Check that the files you are commiting have correct Copyright
information, including the years. If needed, use "git blame
<filename> to check who modified this file and when.
* Add something in the NEWS file. The NEWS file should contain an
entry for the next release, put your note in there.
* If this commit changes the user manual, update the date on the title
page.
To make a new release:
======================
* Check with the team whether they had plans for this release.
* Update the date in the user manual. Check the right date by using
git log doc/user_guide
and edit doc/user_guide/GyotoManual.tex accordingly.
* Choose a version number. Version is MAJOR.MINOR.MICRO. Bump MAJOR
when significant new feature are there; update MINOR for continued
development of existing features; update MICRO for bugfix or
packaging releasing.
* Edit configure.ac
+ update the version info in AC_INIT
+ update VERSINFO according to
http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
Note that this VERSINFO has nothing to do with the Gyoto version.
+ run autoreconf.
* Edit NEWS
+ add a new entry (or change the one which has not been released yet)
+ mark the release either "ABI n" if the ABI changed, "BUG" if its a
simple backwards-compatible bugfix release, PKG if only the
packaging has been changed.
+ document shortly what has changed in Gyoto: new features,
significant bug fixes...
* Regenerate ChangeLog:
+ run "git log --no-merges > ChangeLog"
+ add an item on top which should correspond to the log message that
you will use for the *next* commit (the one that does the
release). Use "unknown" as commit identifier and the output of
"LANG=C date --rfc-822" as date.
* Make clean, configure, make, make check again.
* Commit the changes.
* If releasing another branch than stable: merge this branch into
stable, make sure the two branches can be merged both ways and are
identical, merge stable into master.
* Tag the release using the version as tag name. Use a signed tag:
"git tag -s 1.0.0".
* Take a coffee break.
Coding rules:
=============
Don't use std::atof from cstdlib. Use Gyoto::atof instead. Gyoto::atof
is a wrapper that ensures demical_point is "." and handles special
values like DBL_MAX.
On output (especially to XML), you should also make sure to use the
'C' locale. If using C-style sprintf(), this can be done with:
#include <clocale>
std::string loc(setlocale(LC_NUMERIC, NULL));
setlocale(LC_NUMERIC, "C");
sprintf(txt, fmt, val);
setlocale(LC_NUMERIC, loc.c_str());
If using C++-style streams:
#include <locale>
std::locale Cloc("C");
ostringstream ss;
ss.imbue(Cloc);
ss << val;
Regards, Thibaut.
|
