README-release - master - githubmirror/parted

README-release
200 строк6 KB
Brian C. Lane
README-release: Fix typos in doxygen instructions
14 апр 2026, 23:53
14 апр 2026, 23:536e59466
Here are most of the steps we (maintainers) follow when making a release.

* start from a clean, up-to-date git directory.

    git checkout master; git pull

* Update gnulib to the current version

    git submodule foreach git pull origin master

  Note that the first time you clone the repo you will need to initialize
  the submodule with:

    git submodule update --init ./gnulib/

* Copy the new bootstrap from gnulib:

    cp gnulib/build-aux/bootstrap .

  And then commit the change.

* Adjust shared-library settings, CURRENT:REVISION:AGE in both files,
  libparted/{fs/,}Makefile.am
  following the instructions in the comments there and commit any changes.

* Ensure that the desired versions of autoconf, automake, etc.
  are in your PATH.  See the buildreq list in bootstrap.conf for
  the complete list. Depending on the distribution you are using the
  package names below may be slightly different:

  Fedora Packages
   - libtool
   - autoconf
   - automake
   - bc
   - gperf
   - gcc
   - make
   - texinfo-tex
   - po4a
   - e2fsprogs-devel
   - libuuid-devel
   - libblkid-devel
   - device-mapper-devel
   - ncurses-devel
   - readline-devel
   - check
   - check-devel
   - pkgconfig
   - dosfstools
   - sudo
   - perl-Digest-CRC
   - perl-Digest-SHA3
   - xfsprogs
   - hfsplus-tools
   - btrfs-progs
   - ntfsprogs
   - wget

  Debian Packages
   - libtool
   - gcc
   - make
   - texinfo
   - texlive
   - po4a
   - uuid-dev
   - libdevmapper-dev
   - ncurses-dev
   - libreadline-dev
   - check
   - pkg-config
   - dosfstools
   - sudo
   - libdigest-crc-perl
   - libdigest-sha3-perl
   - xfsprogs
   - hfsprogs
   - btrfs-progs
   - ntfs-3g

* Ensure that you're on "master" with no uncommitted diffs.
  This should produce no output: git checkout master; git diff

* Run git clean -xdf first, or make maintainer-clean

* Run bootstrap. This downloads any new translations and creates ./configure

    ./bootstrap

* Run ./configure
  Note that currently -Werror is not included, warnings are intended to be
  fixed, but should not block building unless they are in a new commit.

* If the copyright has not been updated this year, run:

  make update-copyright

  and then commit the changes.

* Pre-release testing:
  Run "make check syntax-check"

  syntax-check may complain about various things. Fix them and commit them.

* Run "make distcheck"

* Run the following to set the date, version number, and release
  type [stable/alpha/beta] on line 3 of NEWS, commit that, and
  tag the release:

    build-aux/do-release-commit-and-tag X.Y stable

* Run the following to create release tarballs.  Your choice selects the
  corresponding upload-to destination in the emitted gnupload command.
  The different destinations are specified in cfg.mk.  See the definitions
  of gnu_ftp_host-{alpha,beta,stable}.

    # "TYPE" must be stable, beta or alpha
    make TYPE

* Test the tarball.  copy it to a few odd-ball systems and ensure that
  it builds and passes all tests.

* While that's happening, write the release announcement that you will
  soon post.

Once all the builds and tests have passed,

* If this is your first time creating a release you will need to have your gpg
  key added to the ftp system. Read this page

  https://www.gnu.org/prep/maintain/html_node/Automated-Upload-Registration.html

  for the details of how to request this.

* Run the gnupload command that was suggested by your "make stable" run above.

  If you are using a different gpg key to sign the releases you will need to
  pass --user <EMAIL> to gnupload to select it.

* Wait a few minutes (maybe up to 30?) and then use the release URLs to
  download all tarball/signature pairs and use gpg --verify to ensure
  that they're all valid.

* Push the NEWS-updating changes and the new tag:

    v=$(cat .prev-version)
    git push origin master tag v$v

* Announce it on Savannah first, so you can include the preferable
  savannah.org announcement link in the email message.

  From here:
    https://savannah.gnu.org/projects/parted/
  click on the "submit news", then write something like the following:
  (If there is no such button, then enable "News" for the project via
   the Main -> "Select Features" menu item, or via this link:
   https://savannah.gnu.org/project/admin/editgroupfeatures.php?group=parted)

    Subject: parted-X.Y released [stable]
    +verbatim+
    ...paste the announcement here...
    -verbatim-

  Then go here to approve it:
    https://savannah.gnu.org/news/approve.php?group=parted

* Send the announcement email message.

* After each non-alpha release, update the on-line manual accessible via

    http://www.gnu.org/software/parted/manual/

  by running this:

    build-aux/gnu-web-doc-update

* Alert the Translation Project that there is a new .pot file available
  This should also be done for the Alpha release

  See: https://translationproject.org/html/maintainers.html for details.

  Send an email to coordinator@translationproject.org with a subject of parted-x.y.z.pot and a link
  to the tar.xz file mentioned in the release.

* Update the API documentation webpage

  Run `mkdir -p doc/libparted/API && doxygen Doxyfile` from the top of the tree, after having run
  make. Then copy the contents of the API directory to the cvs web manually.

  * Check out the parted web directory with cvs using your login. See https://savannah.gnu.org/cvs/?group=parted for details on group membership.

    cvs -z3 -d:ext:USER@cvs.savannah.gnu.org:/web/parted co parted

  * Copy the new API into the ./api/ directory
  * manually fiddle with adding new files, changed files, and removing removed files.
  * commit the changes

    cvs ci -m "Update API ..."