Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Note out of date section.


  1. Check out the branch with:

    No Format
    git checkout branch-X.Y

  2. Update the version:

    No Format
    mvn versions:set -DnewVersion=X.Y.Z -DgenerateBackupPoms=false

    1. Update the version number in share/VERSION.txt to be X.Y.Z. Be sure NOT to leave a trailing newline.
    2. Update the version number in lang/js/package.json to X.Y.Z.  Update or regenerate lang/js/package-lock.json.
    3. Update the version number in pom-XXXX.xml used for unit tests in the lang/java/maven-plugin/src/test/resources directory too.
    4. Update the versions in doc/examples/java-examplesexample and doc/examples/mr-examplesexample.
  3. Commit the update to the release branch.

    No Format
    git commit -am "Preparing for release X.Y.Z"

  4. Add the fix version X.Y.Z to the Avro JIRA
  5. If not already done, cherry-pick desired patches from master into the branch and commit these changes.

    No Format
    git checkout branch-X.Y
    git cherry-pick <commit>

  6. For each patch merged, change the fix version for the JIRA issue to be X.Y.Z
  7. Go through JIRA, and git log to be sure that the issues included in the branch match in each location.
  8. Update the version number in lang/c/ (the variables libavro_micro_versionlibavro_interface_age and libavro_binary_age) according to the libtool versioning rules as described in that file. Note the libtool version number is completely unrelated to the Avro release version number.

  9. Commit these changes.

    No Format
    git commit -am "Preparing to build X.Y.Z"

  10. Tag the release candidate (R is the release candidate number):

    No Format
    git tag -s release-X.Y.Z-rcR -m "Avro X.Y.Z rcR release."

  11. Push the release tag and branch changes:

    No Format
    git push apache release-X.Y.Z-rcR
    git push apache branch-X.Y


  1. Tag the release:

    No Format
    git checkout release-X.Y.Z-rcR
    git tag -s release-X.Y.Z -m "Avro X.Y.Z release."
    git push apache release-X.Y.Z

  2. Copy release files to the release repository (PMC permissions required):

    No Format
    svn copy \ -m "Avro X.Y.Z release."

  3. The release directory usually contains just two releases, the most recent from two branches, with a link named 'stable' to the most recent recommended version (PMC permissions required):

    No Format
    svn co avro-release-dist
    cd avro-release-dist
    svn rm avro-A.B.C; rm stable
    ln -s avro-X.Y.Z stable
    svn commit -m  "Avro X.Y.Z release."

  4. Publish Java artifacts to the Maven repository:
    Find the Staging Repository and release it.
  5. Publish Python artifacts to PyPI. To do this you'll need an account on PyPi, and write access to the Avro package - ask the existing owners for permission if you don't have it. 

    No Format
    # To install twine in the docker image
    export PATH=~/.local/bin/:$PATH
    python3 -m pip install --user --upgrade twine pip
    mkdir -p tmp/py
    cd tmp/py
    tar xvfz ../../dist/py/avro-X.Y.X.tar.gz
    cd avro-X.Y.Z
    python sdist
    twine upload dist/*

  6. Publish Ruby artifacts to RubyGems. Again, you'll need an account and you need to be an owner.

    No Format
    gem push dist/ruby/avro-X.Y.Z.gem

  7. Publish JavaScript artifacts to npm. Again, you'll need an account and you need to be an owner.

    No Format
    npm login
    npm publish dist/js/avro-js-X.Y.Z.tgz

  8. Publish C# artifacts to NuGet. Again, you'll need an account and you need to be an owner. You also need to generate an additional key to publish.

    No Format
    mkdir -p tmp/csharp
    cd tmp/csharp
    tar xvfz ../../dist/csharp/avro-csharp-X.Y.Z.tar.gz
    dotnet nuget push main/Apache.Avro.X.Y.Z.nupkg -k YOUR_KEY -s
    dotnet nuget push codegen/Apache.Avro.Tools.X.Y.Z.nupkg -k YOUR_KEY -s
    dotnet nuget push codec/Avro.File.Snappy/Apache.Avro.File.Snappy.X.Y.Z.nupkg -k YOUR_KEY -s
    dotnet nuget push codec/Avro.File.BZip2/Apache.Avro.File.BZip2.X.Y.Z.nupkg -k YOUR_KEY -s
    dotnet nuget push codec/Avro.File.XZ/Apache.Avro.File.XZ.X.Y.Z.nupkg -k YOUR_KEY -s
    dotnet nuget push codec/Avro.File.Zstandard/Apache.Avro.File.Zstandard.X.Y.Z.nupkg -k YOUR_KEY -s

  9. Publish Perl artifacts to CPAN. Again, you'll need an account and you need to be an owner.

    No Format
    cpan-upload -u YOUR_ID Avro-X.Y.Z.tar.gz

  10. Wait 24 hours for release to propagate to mirrors.
  11. Prepare to edit the website. THIS SECTION IS OUT OF DATE.  TODO!

    No Format
    svn co

  12. Update the documentation links in author/content/xdocs/site.xml.
  13. Update the release news in author/content/xdocs/releases.xml.
  14. Run Apache Forrest using Apache Ant. Example is with forrest installed using homebrew:

    No Format
    cd site
    ant -Dforrest.home=/usr/local/Cellar/apache-forrest/0.9/
    # Alternatively, using forrest inside the avro-build docker.
    ant -Dforrest.home=/usr/local/apache-forrest

  15. Copy the new release docs, which are generated at the dist step, to website and update the docs/current link:

    No Format
    tar xzf dist/avro-doc-X.Y.Z.tar.gz
    mv avro-doc-X.Y.Z ../site/publish/docs/X.Y.Z
    cd ../site/publish/docs
    svn add X.Y.Z
    rm current
    ln -s X.Y.Z current
    svn commit -m "Adding documentation for release X.Y.Z."

  16. Send an announcement email to the the mailing lists: and once the site changes are visible. Use your personal `` email address or it will be refused.
  17. In Jira, "release" the version. Visit the Manage versions page. You need to have the "Admin" role in Avro's Jira for this step and the next.
  18. In Jira, close issues resolved in the release. Disable mail notifications for this bulk change.
  19. Update the release information in Apache Committee Report Helper (you should receive a reminder by email).
  20. Create a new release on Github:
    1. Draft a new release, using the release-X.Y.Z tag created in step 1.
    2. Release title: Apache Avro X.Y.Z