File: README.Developers

package info (click to toggle)
gyoto 1.3.1-1
  • links: PTS, VCS
  • area: main
  • in suites: bullseye, buster, sid
  • size: 8,588 kB
  • sloc: cpp: 33,490; sh: 18,775; xml: 2,633; python: 1,424; makefile: 681; ansic: 314
file content (73 lines) | stat: -rw-r--r-- 2,508 bytes parent folder | download | duplicates (2)
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
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.

Regards, Thibaut.