Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FRR: Update Community.md to reflect release process #1784

Merged
merged 1 commit into from
Mar 1, 2018
Merged

FRR: Update Community.md to reflect release process #1784

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 30 additions & 0 deletions COMMUNITY.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -492,6 +492,36 @@ In all cases, compatibility pieces should be marked with compiler/preprocessor
annotations to print warnings at compile time, pointing to the appropriate
update path. A `-Werror` build should fail if compatibility bits are used.

### Release Process/Schedule

FRR employs a <MAJOR>.<MINOR>.<BUGFIX> versioning scheme.

* MAJOR - Significant new features or multiple minor features
A example of a MAJOR feature is a New Routing Protocol
* MINOR - Smaller Features
A example of a MINOR feature is the addition of the BGP Shutdown feature.
* BUGFIX - Fixes for actual bugs and/or security issues.

We will pull a new development branch for the next release every 4 months.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't master the 'development' branch? Perhaps a different name would be less confusing.

The current schedule is Feb/June/October 1. The decision for a MAJOR/MINOR
release is made at the time of branch pull based on what has been received
the previous 4 months. The branch name will be dev/MAJOR.MINOR. At
this point in time the master branch configure.ac and packaging systems
will be updated to reflect the next possible release name to allow
for easy distinguishing. Additionally the new dev branch will have
these files updated too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The expectation / process covering what happens during the 1st month should be defined / captured. (Is it more than changing configure.ac and packaging? if not, why a month, if yes, what...)

After one month the development branch will be renamed to
stable/MAJOR.MINOR. This process is not held up unless a crash or
security issue has been found and needs to be addressed. Issues
being fixed will not cause a delay.

Bug fix releases are at 1 month intervals until next MAJOR.MINOR is
pulled. Then at that time as needed for issues filed.

Security issues are fixed for 1 year minimum on old releases and
normal bug fixes for the current and previous release

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what happens on release? perhaps the branch renamed/created called rel/MAJOR.MINOR?

### Miscellaneous

When in doubt, follow the guidelines in the Linux kernel style guide, or ask on
Expand Down