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 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 55 CHECKING DOCS ON readthedocs
31 56  
32 57 To check docs on readthedocs.io without running all of CI, push to the
... ... @@ -276,7 +301,8 @@ RELEASE PREPARATION
276 301 ensure that any exceptions thrown by the library are caught and
277 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 307 * Increment shared library version information as needed
282 308 (`LT_CURRENT` in `configure.ac`)
... ... @@ -287,14 +313,14 @@ RELEASE PREPARATION
287 313 * manual/conf.py
288 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 325 * Performance test is included with binary compatibility steps. Even
300 326 if releasing a new major release and not doing binary compatibility
... ...