Skip to content

Egeria Release Notes Release process

Update the Release guide

Release notes are available as part of the online documentation. In order to update these release notes, you should

1. Agree schedule
  • Agree on appropriate dates for branching given expected duration for testing, vacation / public holidays
    • Typically, allow 2-4 days between branching and availability
    • Communicate with team on regular calls, and via #egeria-github on Slack
    • In the last week before branching discuss holding off on any big changes in main that could destabilize the codebase
2. Track remaining issues and PRs
  • Ensure any required issues / PRs for the release have the correct milestone set
    • Move any issues / PRs not expected to make / not required for the release to a future milestone
    • Aim to branch when most issues / PRs are complete to minimize back-porting from main, but not at the expense of impacting ongoing main development
    • Agree final branch date / criteria
3. change the release guide content

4. test locally

5. merge changes

Tell the community the release has been made

Post a slack update on the egeria-announce channel to tell the community. For example :

`Egeria 3.5 has been released Available via : Source: git https://github.com/odpi/egeria/releases/tag/V3.5 Maven artifacts: Maven Central (via maven/gradle) (may take a few hours to mirror) Container images - https://quay.io/repository/odpi/egeria?tab=tags (no pull request limits) & https://hub.docker.com/r/odpi/egeria (includes arm64) k8s Helm Chart repository https://github.com/odpi/egeria-charts (now supports arm64) Release notes at https://odpi.github.io/egeria-docs/release-notes/3-5/ A full list of changes can be found at https://github.com/odpi/egeria/compare/V3.4...V3.5 (edited)

Open metadata and governance for enterprises - automatically capturing, managing and exchanging metadata between tools and platforms, no matter the vendor `

Raise an issue or comment below