@@ -25,18 +25,26 @@ To publish a new release Debian package, perform the following:
25
25
26
26
1. Change to the packaging branch, ``git checkout debian/unstable ``, and make sure
27
27
the working directorty is clean, ``git status ``, and up-to-date, ``git pull ``.
28
- 2. Merge the release tag, ``git merge 1.xx.y ``; if there is a conflict (which
29
- should be rare), then it may be better to pass some additional options,
30
- ``git merge -sort -Xtheirs 1.xx.y ``.
28
+ 2. Because it is possible to have divergences between release branches, some
29
+ special procedures are needed. Execute the following sequence of commands
30
+ (substituting version numbers as appropriate):
31
+
32
+ .. code-block :: console
33
+
34
+ $ git merge --no-commit --no-ff 1.xx.y # may result in conflicts
35
+ $ git checkout HEAD -- debian # ensures debian/ dir is preserved
36
+ $ git add . # prepare to resolve conflicts
37
+ $ git checkout --no-overlay 1.xx.y -- . ':!debian' # resolve conflicts
38
+ $ git add .
39
+ $ git commit
40
+
31
41
3. Verify that there are no extraneous differences from the release tag,
32
42
``git diff 1.xx.y..HEAD --stat -- . ':!debian' ``; the command should produce
33
43
no output, and if any output is shown then that indicates differences in
34
44
files outside the ``debian/ `` directory.
35
45
4. If there were any files outside the ``debian/ `` directory listed in the last
36
- step then replace them, ``git checkout 1.xx.y -- path/to/file1 path/to/file2 ``.
37
- Commit these changes,
38
- ``git commit -m "Fix-up, post Merge tag '1.xx.y' into debian/unstable" `` and
39
- repeat step 3.
46
+ step then something has gone wrong. Discard the changes on the branch and
47
+ start again.
40
48
5. Create a new changelog entry (use the command ``dch -i `` to ensure proper
41
49
formatting), then adjust the version number on the top line of the changelog
42
50
as appropriate.
@@ -51,14 +59,18 @@ To publish a new release Debian package, perform the following:
51
59
files are installed to the proper locations by the proper packages and also
52
60
use ``lintian `` on the ``.changes `` file in order to confirm that there are no
53
61
unexpected errors or warnings; the ``lintian `` used for this check should
54
- always be the latest version as it is found in the unstable distribution)
62
+ always be the latest version as it is found in the unstable distribution).
55
63
9. If any changes are needed, make them, commit them, and rebuild the package.
56
64
57
65
.. note :: It may be desirable to squash multiple commits down to a single commit before building the final packages.
58
66
59
- 10. Once the final packages are built, they can be signed and uploaded and the
60
- version can be tagged using the ``--git-tag `` option of ``gbp buildpackage ``.
61
- The best approach is to build the packages, prepare everything and then
62
- upload. Once the archive has accepted the upload, then execute
67
+ 10. Mark the package ready for release with the ``dch -r `` command, commit the
68
+ resulting changes (after inspecting them),
69
+ ``git commit debian/changelog -m 'mark ready for release' ``.
70
+ 11. Build the final packages. Once the final packages are built, they can be
71
+ signed and uploaded and the version can be tagged using the ``--git-tag ``
72
+ option of ``gbp buildpackage ``. The best approach is to build the packages,
73
+ prepare everything and then upload. Once the archive has accepted the
74
+ upload, then execute
63
75
``gbp buildpackage --git-tag --git-tag-only --git-sign-tags `` and push the
64
76
commits on the ``debian/unstable `` branch as well as the new signed tag.
0 commit comments