release_method(3)
π NAME π
release_method β Release Numbering and Methodology π straight out of the avr-libc manual, section 3, bestie π
π Release Version Numbering Scheme π
Okay so a release number is literally three parts β a major number, a minor number, and a revision number β and each one is separated by a dot. Periodt. π
The major number is currently 2, and that's because the multilib layout has been adapted to the fairly different one used starting with AVR-GCC version 5. But ngl, it's still believed to be generally API-compatible with release versions 1.x. π
Back in the day (up to 1.6.x), even minor numbers were used to indicate 'stable' releases, and odd minor numbers were reserved for development branches/versions. The way that the odd one was never really used, and maintaining a stable branch that eventually became effectively the same as the development version proved to be just a cumbersome and tedious jobβ¦ yeah, that scheme was given up in early 2010. So starting with 1.7.0, every minor number will be used. β¨ Minor numbers get bumped upon judgement of the development team, whenever it seems appropriate, but at least in cases where some API was changed. π
Starting with version 1.4.0, a file <avr/version.h> indicates the library version of an installed library tree. Iconic. π¦
π οΈ Releasing AVR Libc π οΈ
The information in this section is only relevant to AVR Libc developers and can be ignored by end users. π
Note: In what follows, I assume you know how to use SVN and how to checkout multiple source trees in a single directory without having them clobber each other. If you don't know how to do this, you probably shouldn't be making releases or cutting branches. π
πΈ Creating an SVN branch πΈ
The following steps should be taken to cut a branch in SVN (assuming $username is set to your savannah username):
- Check out a fresh source tree from SVN trunk. β¨
- Update the
NEWSfile with pending release number and commit to SVN trunk: changeChanges since avr-libc-<last_release>:toChanges in avr-libc-<this_relelase>. - Set the branch-point tag (setting
<major>and<minor>accordingly):
svn copy svn+ssh://$username@svn.savannah.nongnu.org/avr-libc/trunk svn+ssh://$username@svn.savannah.nongnu.org/avr-libc/tags/avr-libc-<major>_<minor>-branchpoint
- Create the branch:
svn copy svn+ssh://$username@svn.savannah.nongnu.org/avr-libc/trunk svn+ssh://$username@svn.savannah.nongnu.org/avr-libc/branches/avr-libc-<major>_<minor>-branch
- Update the package version in
configure.acand commitconfigure.acto SVN trunk: change minor number to next odd value. π - Update the
NEWSfile and commit to SVN trunk: addChanges since avr-libc-<this_release>: - Check out a new tree for the branch:
svn co svn+ssh://$username@svn.savannah.nongnu.org/avr-libc/branches/avr-libc-<major>_<minor>-branch
- Update the package version in
configure.acand commitconfigure.acto SVN branch: change the patch number to90to denote that this now a branch leading up to a release. Be sure to leave the<date>part of the version. ποΈ - Bring the build system up to date by running
bootstrapandconfigure. π₯ - Perform a '
make distcheck' and make sure it succeeds. This will create the snapshot source tarball. This should be considered the first release candidate. π - Upload the snapshot tarball to savannah. βοΈ
- Update the bug tracker interface on Savannah:
Bugs ---> Edit field values ---> Release / Fixed Release - Announce the branch and the branch tag to the
avr-libc-devlist so other developers can checkout the branch. π£
π« Making a release π«
A stable release will only be done on a branch, not from the SVN trunk. No cap. π«
The following steps should be taken when making a release:
- Make sure the source tree you are working from is on the correct branch:
svn switch svn+ssh://$username@svn.savannah.nongnu.org/avr-libc/branches/avr-libc-<major>_<minor>-branch
- Update the package version in
configure.acand commit it to SVN. - Update the gnu tool chain version requirements in the
READMEand commit to SVN. - Update the
ChangeLogfile to note the release and commit to SVN on the branch: addReleased avr-libc-<this_release>. - Update the
NEWSfile with pending release number and commit to SVN: changeChanges since avr-libc-<last_release>:toChanges in avr-libc-<this_relelase>:. π - Bring the build system up to date by running
bootstrapandconfigure. β¨ - Perform a '
make distcheck' and make sure it succeeds. This will create the source tarball. π₯ - Tag the release:
svn copy . svn+ssh://$username@svn.savannah.nongnu.org/avr-libc/tags/avr-libc-<major>_<minor>_<patch>-release
or
svn copy svn+ssh://$username@svn.savannah.nongnu.org/avr-libc/branches/avr-libc-<major>_<minor>-branch svn+ssh://$username@svn.savannah.nongnu.org/avr-libc/tags/avr-libc-<major>_<minor>_<patch>-release
- Upload the tarball to savannah. βοΈ
- Update the
NEWSfile, and commit to SVN: addChanges since avr-libc-<major>_<minor>_<patch>: - Update the bug tracker interface on Savannah:
Bugs ---> Edit field values ---> Release / Fixed Release - Generate the latest documentation and upload to savannah. π
- Announce the release. π£π
The following hypothetical diagram should help clarify version and branch relationships. π§ β¨
Release treeRelease tree
And that's the whole vibe, bestie β this page is from the avr-libc manual, section 3, and the version/date stamped on it are Version 2.1.0 and Sat Jan 29 2022. π«Ά Slay, go cut that branch. π
π
π¦ where this page comes from
- fedora 43: avr-libc 2.2.1-3.fc43 Β· BSD-3-Clause
- fedora 44: avr-libc 2.2.1-5.fc44 Β· BSD-3-Clause
- opensuse-leap 16.0: avr-libc 2.1.0-bp160.1.33 Β· BSD-3-Clause
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms