OpenSystemsDevelopment / qpdf

Commit 39ad799e2d4fa1ee0b6cddad819d6660665c7894

Authored by Jay Berkenbilt
1 parent dca0c7ea

Change version numbering practice: main is now next 

We have been keeping main's version at the last released version, but
starting now, main's version will always be whatever it would be if
a release were cut from the tip of main.
Inline Side-by-side
Showing 1 changed file with 32 additions and 6 deletions
README-maintainer
  View file @39ad799
@@ -27,6 +27,31 @@ Memory checks: @@ -27,6 +27,31 @@ Memory checks:
27 --enable-werror --disable-shared --enable-maintainer-mode 27 --enable-werror --disable-shared --enable-maintainer-mode
28 28
29 29
  30 +VERSIONS
  31 +
  32 +* The version number on the main branch is whatever the version would
  33 + be if the top of the branch were released. If the most recent
  34 + release is version a.b.c, then
  35 +
  36 + * If there are any ABI-breaking changes since the last release,
  37 + main's version is a+1.0.0
  38 + * Else if there is any new public API, main's version is a.b+1.0
  39 + * Else if there are any code changes, main's version is a.b.c+1
  40 +
  41 +* Whenever we bump the version number, bump shared library versions as
  42 + well.
  43 +
  44 +* Every released major/minor version has an a.b branch which is used
  45 + primarily for documentation but could potentially be used to create
  46 + a new patch release after main has moved on. We don't do that as a
  47 + rule, but there's no reason we couldn't do it if main had unreleased
  48 + ABI/API changes that were still in flux and an important bug fix was
  49 + needed on the most recent release. In that case, a release can be
  50 + cut from a release branch and then either main can be rebased from
  51 + there or the changes can be merged back, depending on the amount of
  52 + drift.
  53 +
  54 +
30 CHECKING DOCS ON readthedocs 55 CHECKING DOCS ON readthedocs
31 56
32 To check docs on readthedocs.io without running all of CI, push to the 57 To check docs on readthedocs.io without running all of CI, push to the
@@ -276,7 +301,8 @@ RELEASE PREPARATION @@ -276,7 +301,8 @@ RELEASE PREPARATION
276 ensure that any exceptions thrown by the library are caught and 301 ensure that any exceptions thrown by the library are caught and
277 converted. See `trap_errors` in qpdf-c.cc. 302 converted. See `trap_errors` in qpdf-c.cc.
278 303
279 -* Update versions and shared library details 304 +* Double check versions and shared library details. They should
  305 + already be up to date in the code.
280 306
281 * Increment shared library version information as needed 307 * Increment shared library version information as needed
282 (`LT_CURRENT` in `configure.ac`) 308 (`LT_CURRENT` in `configure.ac`)
@@ -287,14 +313,14 @@ RELEASE PREPARATION @@ -287,14 +313,14 @@ RELEASE PREPARATION
287 * manual/conf.py 313 * manual/conf.py
288 `make_dist` verifies this consistency. 314 `make_dist` verifies this consistency.
289 315
290 - * Update release notes in manual. Look at diffs and ChangeLog.  
291 - Update release date in `manual/release-notes.rst`. 316 + * Run ./autogen.sh
292 317
293 - * Add a release entry to ChangeLog: "x.y.z: release" 318 +* Update release notes in manual. Look at diffs and ChangeLog.
  319 + Update release date in `manual/release-notes.rst`.
294 320
295 - * Run ./autogen.sh 321 +* Add a release entry to ChangeLog: "x.y.z: release"
296 322
297 - * Commit title: "Prepare x.y.z release" 323 +* Commit title: "Prepare x.y.z release"
298 324
299 * Performance test is included with binary compatibility steps. Even 325 * Performance test is included with binary compatibility steps. Even
300 if releasing a new major release and not doing binary compatibility 326 if releasing a new major release and not doing binary compatibility