]>
Commit | Line | Data |
---|---|---|
b0ff7312 QY |
1 | Developing for FRRouting |
2 | ========================= | |
3 | ||
4 | ## Table of Contents | |
f6ee5b52 | 5 | |
4765f35e | 6 | [TOC] |
f6ee5b52 | 7 | |
02fe6f86 DL |
8 | ## General note on this document |
9 | ||
10 | This document is "descriptive/post-factual" in that it documents pratices that | |
11 | are in use; it is not "definitive/pre-factual" in prescribing practices. | |
12 | ||
13 | This means that when a procedure changes, it is agreed upon, then put into | |
14 | practice, and then documented here. If this document doesn't match reality, | |
15 | it's the document that needs to be updated, not reality. | |
16 | ||
17 | ||
f6ee5b52 DL |
18 | ## Git Structure |
19 | ||
c545559d | 20 | The master Git for FRRouting resides on Github at |
b0ff7312 | 21 | [https://github.com/frrouting/frr](https://github.com/FRRouting/frr) |
f6ee5b52 | 22 | |
9b7939d9 DL |
23 | ![git branches continually merging to the left from 3 lanes; float-right](doc/git_branches.svg |
24 | "git branch mechanics") | |
25 | ||
f1423462 QY |
26 | There is one main branch for development and a release branch for each major |
27 | release. | |
f6ee5b52 | 28 | |
02fe6f86 | 29 | New contributions are done against the head of the master branch. The CI |
f1423462 QY |
30 | systems will pick up the Github Pull Requests or the new patch from Patchwork, |
31 | run some basic build and functional tests. | |
f6ee5b52 | 32 | |
f1423462 QY |
33 | For each major release (1.0, 1.1 etc) a new release branch is created based on |
34 | the master. | |
f6ee5b52 | 35 | |
f1423462 QY |
36 | There was an attempt to use a "develop" branch automatically maintained by the |
37 | CI system. This is not currently in active use, though the system is | |
38 | operational. If the "develop" branch is in active use and this paragraph is | |
39 | still here, this document obviously wasn't updated. | |
02fe6f86 | 40 | |
f6ee5b52 DL |
41 | |
42 | ## Programming language, Tools and Libraries | |
43 | ||
c545559d QY |
44 | The core of FRRouting is written in C (gcc or clang supported) and makes use of |
45 | GNU compiler extensions. A few non-essential scripts are implemented in Perl | |
46 | and Python. FRRouting requires the following tools to build distribution | |
47 | packages: automake, autoconf, texinfo, libtool and gawk and various libraries | |
48 | (i.e. libpam and libjson-c). | |
f6ee5b52 DL |
49 | |
50 | If your contribution requires a new library or other tool, then please | |
c545559d QY |
51 | highlight this in your description of the change. Also make sure it’s supported |
52 | by all FRRouting platform OSes or provide a way to build without the library | |
53 | (potentially without the new feature) on the other platforms. | |
f6ee5b52 | 54 | |
f1423462 QY |
55 | Documentation should be written in Tex (.texi) or Markdown (.md) format with a |
56 | preference for Markdown. | |
f6ee5b52 DL |
57 | |
58 | ||
b0ff7312 QY |
59 | ## Mailing lists |
60 | ||
61 | Italicized lists are private. | |
62 | ||
63 | | Topic | List | | |
64 | |--------------------------------|------------------------------| | |
65 | | Development | dev@lists.frrouting.org | | |
66 | | Users & Operators | frog@lists.frrouting.org | | |
67 | | Announcements | announce@lists.frrouting.org | | |
68 | | _Security_ | security@lists.frrouting.org | | |
69 | | _Technical Steering Committee_ | tsc@lists.frrouting.org | | |
f6ee5b52 | 70 | |
cccfb0ea LB |
71 | The Development list is used to discuss and document general issues |
72 | related to project development and governance. The public Slack | |
73 | instance, frrouting.slack.com, and weekly technical meetings provide a | |
74 | higher bandwidth channel for discussions. The results of such | |
75 | discussions must be reflected in updates, as appropriate, to code (i.e., | |
76 | merges), [github](https://github.com/FRRouting/frr/issues) tracked | |
77 | issues, and for governance or process changes, updates to the | |
78 | Development list and either this file or information posted at | |
79 | [https://frrouting.org/](https://frrouting.org/). | |
80 | ||
f6ee5b52 DL |
81 | |
82 | ### Changelog | |
83 | ||
84 | The changelog will be the base for the release notes. A changelog entry for | |
85 | your changes is usually not required and will be added based on your commit | |
86 | messages by the maintainers. However, you are free to include an update to | |
87 | the changelog with some better description. The changelog will be the base | |
88 | for the release notes. | |
89 | ||
90 | ||
91 | ## Submitting Patches and Enhancements | |
92 | ||
b0ff7312 QY |
93 | ### Pre-submission Checklist |
94 | ||
500075b7 | 95 | * Format code (see [Developer's Guidelines](#developers-guidelines)) |
b0ff7312 QY |
96 | * Verify and acknowledge license (see [License for contributions](#license-for-contributions)) |
97 | * Ensure you have properly signed off (see [Signing Off](#signing-off)) | |
98 | * Test building with various configurations: | |
99 | * `buildtest.sh` | |
100 | * Verify building source distribution: | |
101 | * `make dist` (and try rebuilding from the resulting tar file) | |
102 | * Run unit tests: | |
103 | * `make test` | |
104 | * Document Regression Runs and plans for continued maintenance of the feature | |
105 | ||
f6ee5b52 DL |
106 | ### License for contributions |
107 | ||
c545559d | 108 | FRRouting is under a “GPLv2 or later” license. Any code submitted must be |
f6ee5b52 DL |
109 | released under the same license (preferred) or any license which allows |
110 | redistribution under this GPLv2 license (eg MIT License). | |
111 | ||
b0ff7312 QY |
112 | ### Signing Off |
113 | ||
114 | Code submitted to FRRouting must be signed off. We have the same requirements | |
115 | for using the signed-off-by process as the Linux kernel. In short, you must | |
116 | include a signed-off-by tag in every patch. | |
f6ee5b52 | 117 | |
b0ff7312 QY |
118 | `Signed-off-by:` this is a developer's certification that he or she has the |
119 | right to submit the patch for inclusion into the project. It is an agreement to | |
120 | the Developer's Certificate of Origin (below). Code without a proper signoff | |
4b8ac525 | 121 | can not and will not be merged. |
b0ff7312 QY |
122 | |
123 | If you are unfamiliar with this process, you should read the [official policy | |
78b7a6e3 | 124 | at kernel.org](https://www.kernel.org/doc/html/latest/process/submitting-patches.html) and |
b0ff7312 QY |
125 | you might find this article about [participating in the Linux community on the |
126 | Linux Foundation | |
127 | website](http://www.linuxfoundation.org/content/how-participate-linux-community-0) | |
128 | to be a helpful resource. | |
129 | ||
130 | In short, when you sign off on a commit, you assert your agreement to all of | |
131 | the following: | |
f6ee5b52 DL |
132 | |
133 | > Developer's Certificate of Origin 1.1 | |
134 | > | |
135 | > By making a contribution to this project, I certify that: | |
136 | > | |
137 | > (a) The contribution was created in whole or in part by me and I | |
138 | > have the right to submit it under the open source license | |
139 | > indicated in the file; or | |
140 | > | |
141 | > (b) The contribution is based upon previous work that, to the best | |
142 | > of my knowledge, is covered under an appropriate open source | |
143 | > license and I have the right under that license to submit that | |
144 | > work with modifications, whether created in whole or in part | |
145 | > by me, under the same open source license (unless I am | |
146 | > permitted to submit under a different license), as indicated | |
147 | > in the file; or | |
148 | > | |
149 | > (c) The contribution was provided directly to me by some other | |
150 | > person who certified (a), (b) or (c) and I have not modified | |
151 | > it. | |
152 | > | |
153 | > (d) I understand and agree that this project and the contribution | |
154 | > are public and that a record of the contribution (including all | |
155 | > personal information I submit with it, including my sign-off) is | |
156 | > maintained indefinitely and may be redistributed consistent with | |
157 | > this project or the open source license(s) involved. | |
158 | ||
b0ff7312 | 159 | ### What do I submit my changes against? |
e0ba80e2 DS |
160 | |
161 | We've documented where we would like to have the different fixes applied at | |
162 | https://github.com/FRRouting/frr/wiki/Where-Do-I-create-a-Pull-Request-against%3F | |
f1423462 QY |
163 | If you are unsure where your submission goes, look at that document or ask a |
164 | project maintainer. | |
f6ee5b52 | 165 | |
b0ff7312 | 166 | ### Github pull requests |
f6ee5b52 | 167 | |
b0ff7312 | 168 | The preferred method of submitting changes is a Github pull request. Code |
f1423462 QY |
169 | submitted by pull request will be automatically tested by one or more CI |
170 | systems. Once the automated tests succeed, other developers will review your | |
171 | code for quality and correctness. After any concerns are resolved, your code | |
172 | will be merged into the branch it was submitted against. | |
f6ee5b52 | 173 | |
b0ff7312 | 174 | ### Patch submission via mailing list |
f6ee5b52 | 175 | |
b0ff7312 QY |
176 | As an alternative submission method, a patch can be mailed to the development |
177 | mailing list. Patches received on the mailing list will be picked up by | |
178 | Patchwork and tested against the latest development branch. | |
f6ee5b52 DL |
179 | |
180 | The recommended way to send the patch (or series of NN patches) to the list is | |
b0ff7312 | 181 | by using `git send-email` as follows (assuming they are the N most recent |
f6ee5b52 DL |
182 | commit(s) in your git history: |
183 | ||
184 | ``` | |
b0ff7312 | 185 | git send-email -NN --annotate --to=dev@lists.frrouting.org |
f6ee5b52 DL |
186 | ``` |
187 | ||
188 | If your commits do not already contain a `Signed-off-by` line, then use the | |
b0ff7312 QY |
189 | following command to add it (after making sure you agree to the Developer |
190 | Certificate of Origin as outlined above): | |
f6ee5b52 DL |
191 | |
192 | ``` | |
b0ff7312 | 193 | git send-email -NN --annotate --signoff --to=dev@lists.frrouting.org |
f6ee5b52 DL |
194 | ``` |
195 | ||
b0ff7312 QY |
196 | Submitting multi-commit patches as a Github pull request is **strongly |
197 | encouraged** and increases the probability of your patch getting reviewed and | |
198 | merged in a timely manner. | |
f6ee5b52 DL |
199 | |
200 | ||
201 | ## After submitting your changes | |
202 | ||
203 | * Watch for Continuous Integration (CI) Test results | |
204 | * You should automatically receive an email with the test results within | |
205 | less than 2 hrs of the submission. If you don’t get the email, then check | |
206 | status on the github pull request (if submitted by pull request) or on | |
4765f35e | 207 | Patchwork at |
b0ff7312 | 208 | [https://patchwork.frrouting.org](https://patchwork.frrouting.org) (if |
4765f35e | 209 | submitted as patch to mailing list). |
4b8ac525 QY |
210 | * Please notify the development mailing list if you think something doesn’t |
211 | work. | |
f6ee5b52 DL |
212 | * If the tests failed: |
213 | * In general, expect the community to ignore the submission until the tests | |
214 | pass. | |
215 | * It is up to you to fix and resubmit. | |
b0ff7312 | 216 | * This includes fixing existing unit (“make test”) tests if your |
f6ee5b52 DL |
217 | changes broke or changed them. |
218 | * It also includes fixing distribution packages for the failing | |
4b8ac525 QY |
219 | platforms (ie if new libraries are required). |
220 | * Feel free to ask for help on the development list. | |
f6ee5b52 DL |
221 | * Go back to the submission process and repeat until the tests pass. |
222 | * If the tests pass: | |
b0ff7312 QY |
223 | * Wait for reviewers. Someone will review your code or be assigned to |
224 | review your code. | |
225 | * Respond to any comments or concerns the reviewer has. | |
226 | * After all comments and concerns are addressed, expect your patch to be | |
227 | merged. | |
f6ee5b52 DL |
228 | * Watch out for questions on the mailing list. At this time there will be a |
229 | manual code review and further (longer) tests by various community members. | |
b0ff7312 | 230 | * Your submission is done once it is merged to the master branch. |
f6ee5b52 DL |
231 | |
232 | ||
a03e3526 | 233 | ## Developer's Guidelines |
f6ee5b52 | 234 | |
53c2f1b7 QY |
235 | ### Commit messages |
236 | ||
237 | Commit messages should be formatted in the same way as Linux kernel commit | |
238 | messages. The format is roughly | |
239 | ||
91a0d75f MS |
240 | ``` |
241 | dir: short summary | |
53c2f1b7 | 242 | |
91a0d75f MS |
243 | extended summary |
244 | ``` | |
53c2f1b7 QY |
245 | |
246 | `dir` should be the top level source directory under which the change was made. | |
247 | For example, a change in bgpd/rfapi would be formatted as: | |
248 | ||
249 | `bgpd: short summary` | |
250 | ||
251 | The first line should be no longer than 50 characters. Subsequent lines should | |
252 | be wrapped to 72 characters. | |
253 | ||
c545559d | 254 | ### Source file header |
f6ee5b52 | 255 | |
4765f35e DL |
256 | New files need to have a Copyright header (see [License for |
257 | contributions](#license-for-contributions) above) added to the file. Preferred | |
258 | form of the header is as follows: | |
f6ee5b52 DL |
259 | |
260 | ``` | |
261 | /* | |
896014f4 DL |
262 | * Title/Function of file |
263 | * Copyright (C) YEAR Author’s Name | |
264 | * | |
265 | * This program is free software; you can redistribute it and/or modify it | |
266 | * under the terms of the GNU General Public License as published by the Free | |
267 | * Software Foundation; either version 2 of the License, or (at your option) | |
268 | * any later version. | |
269 | * | |
270 | * This program is distributed in the hope that it will be useful, but WITHOUT | |
271 | * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or | |
272 | * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for | |
273 | * more details. | |
274 | * | |
275 | * You should have received a copy of the GNU General Public License along | |
276 | * with this program; see the file COPYING; if not, write to the Free Software | |
277 | * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA | |
f6ee5b52 | 278 | */ |
4765f35e DL |
279 | |
280 | #include <zebra.h> | |
f6ee5b52 DL |
281 | ``` |
282 | ||
c545559d | 283 | ### Adding copyright claims to existing files |
f6ee5b52 DL |
284 | |
285 | When adding copyright claims for modifications to an existing file, please | |
286 | preface the claim with "Portions: " on a line before it and indent the | |
287 | "Copyright ..." string. If such a case already exists, add your indented claim | |
288 | immediately after. E.g.: | |
289 | ||
290 | ``` | |
291 | Portions: | |
292 | Copyright (C) 2010 Entity A .... | |
293 | Copyright (C) 2016 Your name [optional brief change description] | |
294 | ``` | |
295 | ||
c545559d | 296 | ### Code formatting |
f6ee5b52 | 297 | |
b0ff7312 QY |
298 | FRR uses Linux kernel style except where noted below. Code which does not |
299 | comply with these style guidelines will not be accepted. | |
02fe6f86 | 300 | |
b0ff7312 | 301 | To assist with compliance, in the project root there is a .clang-format |
6058ea8c QY |
302 | configuration file which can be used with the `clang-format` tool from the LLVM |
303 | project. In the `tools/` directory there is a Python script named `indent.py` | |
304 | that wraps clang-format and handles some edge cases specific to FRR. If you are | |
305 | submitting a new file, it is recommended to run that script over the new file | |
306 | after ensuring that the latest stable release of `clang-format` is in your | |
307 | PATH. | |
02fe6f86 DL |
308 | |
309 | **Whitespace changes in untouched parts of the code are not acceptable in | |
310 | patches that change actual code.** To change/fix formatting issues, please | |
311 | create a separate patch that only does formatting changes and nothing else. | |
312 | ||
b0ff7312 | 313 | #### Style documentation |
6058ea8c | 314 | Kernel and BSD styles are documented externally: |
02fe6f86 | 315 | |
6058ea8c QY |
316 | * [https://www.kernel.org/doc/html/latest/process/coding-style.html](https://www.kernel.org/doc/html/latest/process/coding-style.html) |
317 | * [http://man.openbsd.org/style](http://man.openbsd.org/style) | |
02fe6f86 | 318 | |
6058ea8c | 319 | For GNU coding style, use `indent` with the following invocation: |
f6ee5b52 DL |
320 | |
321 | ``` | |
322 | indent -nut -nfc1 file_for_submission.c | |
323 | ``` | |
324 | ||
6058ea8c QY |
325 | #### Exceptions |
326 | ||
327 | FRR project code comes from a variety of sources, so there are some stylistic | |
c545559d | 328 | exceptions in place. They are organized here by branch. |
02fe6f86 | 329 | |
6058ea8c | 330 | **For `master`:** |
02fe6f86 | 331 | |
6058ea8c | 332 | BSD coding style applies to: |
02fe6f86 | 333 | |
c545559d | 334 | * `ldpd/` |
02fe6f86 | 335 | |
6058ea8c QY |
336 | `babeld` uses, approximately, the following style: |
337 | ||
338 | * K&R style braces | |
339 | * Indents are 4 spaces | |
340 | * Function return types are on their own line | |
341 | ||
342 | ||
343 | **For `stable/3.0` and `stable/2.0`:** | |
344 | ||
345 | GNU coding style apply to the following parts: | |
346 | ||
c545559d QY |
347 | * `lib/` |
348 | * `zebra/` | |
349 | * `bgpd/` | |
350 | * `ospfd/` | |
351 | * `ospf6d/` | |
352 | * `isisd/` | |
353 | * `ripd/` | |
354 | * `ripngd/` | |
355 | * `vtysh/` | |
02fe6f86 | 356 | |
6058ea8c | 357 | BSD coding style applies to: |
02fe6f86 | 358 | |
c545559d | 359 | * `ldpd/` |
02fe6f86 | 360 | |
02fe6f86 | 361 | |
a03e3526 QY |
362 | ### Documentation |
363 | ||
364 | FRRouting is a large and complex software project developed by many different | |
365 | people over a long period of time. Without adequate documentation, it can be | |
366 | exceedingly difficult to understand code segments, APIs and other interfaces. | |
367 | In the interest of keeping the project healthy and maintainable, you should | |
368 | make every effort to document your code so that other people can understand | |
369 | what it does without needing to closely read the code itself. | |
370 | ||
371 | Some specific guidelines that contributors should follow are: | |
372 | ||
373 | * Functions exposed in header files should have descriptive comments above | |
374 | their signatures in the header file. At a minimum, a function comment should | |
375 | contain information about the return value, parameters, and a general summary | |
376 | of the function's purpose. Documentation on parameter values can be omitted | |
377 | if it is (very) obvious what they are used for. | |
378 | ||
379 | Function comments must follow the style for multiline comments laid out in | |
380 | the kernel style guide. | |
381 | ||
382 | Example: | |
383 | ||
384 | ``` | |
385 | /* | |
386 | * Determines whether or not a string is cool. | |
387 | * | |
388 | * @param text - the string to check for coolness | |
389 | * @param is_clccfc - whether capslock is cruise control for cool | |
390 | * @return 7 if the text is cool, 0 otherwise | |
391 | */ | |
392 | int check_coolness(const char *text, bool is_clccfc); | |
393 | ``` | |
394 | ||
395 | The Javadoc-style annotations are not required, but you should still strive to | |
396 | make it equally clear what parameters and return values are used for. | |
397 | ||
398 | * Static functions should have descriptive comments in the same form as above | |
399 | if what they do is not immediately obvious. Use good engineering judgement | |
400 | when deciding whether a comment is necessary. If you are unsure, document | |
401 | your code. | |
402 | ||
403 | * Global variables, static or not, should have a comment describing their use. | |
404 | ||
405 | * **For new code in `lib/`, these guidelines are hard requirements.** | |
406 | ||
407 | ||
408 | If you are contributing code that adds significant user-visible functionality | |
409 | or introduces a new API, please document it in `doc/`. Markdown and LaTeX are | |
410 | acceptable formats, although Markdown is currently preferred for new | |
411 | documentation. This may change in the near future. | |
412 | ||
413 | Finally, if you come across some code that is undocumented and feel like going | |
414 | above and beyond, document it! We absolutely appreciate and accept patches that | |
415 | document previously undocumented code. | |
f6ee5b52 | 416 | |
c545559d | 417 | ### Compile-time conditional code |
f6ee5b52 | 418 | |
f1423462 QY |
419 | Many users access FRR via binary packages from 3rd party sources; compile-time |
420 | code puts inclusion/exclusion in the hands of the package maintainer. Please | |
421 | think very carefully before making code conditional at compile time, as it | |
422 | increases regression testing, maintenance burdens, and user confusion. In | |
423 | particular, please avoid gratuitous `--enable-…` switches to the configure | |
424 | script - in general, code should be of high quality and in working condition, | |
425 | or it shouldn’t be in FRR at all. | |
f6ee5b52 DL |
426 | |
427 | When code must be compile-time conditional, try have the compiler make it | |
c545559d QY |
428 | conditional rather than the C pre-processor so that it will still be checked by |
429 | the compiler, even if disabled. For example, | |
f6ee5b52 DL |
430 | |
431 | ``` | |
432 | if (SOME_SYMBOL) | |
433 | frobnicate(); | |
434 | ``` | |
435 | ||
c545559d | 436 | is preferred to |
f6ee5b52 DL |
437 | |
438 | ``` | |
439 | #ifdef SOME_SYMBOL | |
440 | frobnicate (); | |
441 | #endif /* SOME_SYMBOL */ | |
442 | ``` | |
443 | ||
444 | Note that the former approach requires ensuring that `SOME_SYMBOL` will be | |
445 | defined (watch your `AC_DEFINE`s). | |
7ce0cb3c | 446 | |
c545559d | 447 | ### Debug-guards in code |
7ce0cb3c | 448 | |
f1423462 QY |
449 | Debugging statements are an important methodology to allow developers to fix |
450 | issues found in the code after it has been released. The caveat here is that | |
451 | the developer must remember that people will be using the code at scale and in | |
452 | ways that can be unexpected for the original implementor. As such debugs | |
453 | **MUST** be guarded in such a way that they can be turned off. FRR has the | |
454 | ability to turn on/off debugs from the CLI and it is expected that the | |
455 | developer will use this convention to allow control of their debugs. | |
19c7f43f | 456 | |
c545559d | 457 | ### CLI changes |
19c7f43f | 458 | |
f1423462 QY |
459 | CLI's are a complicated ugly beast. Additions or changes to the CLI should use |
460 | a DEFUN to encapsulate one setting as much as is possible. Additionally as new | |
461 | DEFUN's are added to the system, documentation should be provided for the new | |
462 | commands. | |
e887b2b8 LB |
463 | |
464 | ### Backwards Compatibility | |
465 | ||
f1423462 QY |
466 | As a general principle, changes to CLI and code in the lib/ directory should be |
467 | made in a backwards compatible fashion. This means that changes that are purely | |
468 | stylistic in nature should be avoided, e.g., renaming an existing macro or | |
469 | library function name without any functional change. When adding new parameters | |
470 | to common functions, it is also good to consider if this too should be done in | |
471 | a backward compatible fashion, e.g., by preserving the old form in addition to | |
e887b2b8 LB |
472 | adding the new form. |
473 | ||
f1423462 QY |
474 | This is not to say that minor or even major functional changes to CLI and |
475 | common code should be avoided, but rather that the benefit gained from a change | |
476 | should be weighed against the added cost/complexity to existing code. Also, | |
477 | that when making such changes, it is good to preserve compatibility when | |
478 | possible to do so without introducing maintenance overhead/cost. It is also | |
479 | important to keep in mind, existing code includes code that may reside in | |
480 | private repositories (and is yet to be submitted) or code that has yet to be | |
481 | migrated from Quagga to FRR. | |
817302b8 DL |
482 | |
483 | That said, compatibility measures can (and should) be removed when either: | |
484 | ||
f1423462 QY |
485 | * they become a significant burden, e.g. when data structures change and the |
486 | compatibility measure would need a complex adaptation layer or becomes | |
817302b8 | 487 | flat-out impossible |
f1423462 QY |
488 | * some measure of time (dependent on the specific case) has passed, so that the |
489 | compatibility grace period is considered expired. | |
817302b8 DL |
490 | |
491 | In all cases, compatibility pieces should be marked with compiler/preprocessor | |
492 | annotations to print warnings at compile time, pointing to the appropriate | |
493 | update path. A `-Werror` build should fail if compatibility bits are used. | |
a03e3526 | 494 | |
0908f2bf DS |
495 | ### Release Process/Schedule |
496 | ||
497 | FRR employs a <MAJOR>.<MINOR>.<BUGFIX> versioning scheme. | |
498 | ||
499 | * MAJOR - Significant new features or multiple minor features | |
500 | A example of a MAJOR feature is a New Routing Protocol | |
501 | * MINOR - Smaller Features | |
502 | A example of a MINOR feature is the addition of the BGP Shutdown feature. | |
503 | * BUGFIX - Fixes for actual bugs and/or security issues. | |
504 | ||
505 | We will pull a new development branch for the next release every 4 months. | |
506 | The current schedule is Feb/June/October 1. The decision for a MAJOR/MINOR | |
507 | release is made at the time of branch pull based on what has been received | |
508 | the previous 4 months. The branch name will be dev/MAJOR.MINOR. At | |
509 | this point in time the master branch configure.ac and packaging systems | |
510 | will be updated to reflect the next possible release name to allow | |
511 | for easy distinguishing. Additionally the new dev branch will have | |
512 | these files updated too. | |
513 | ||
514 | After one month the development branch will be renamed to | |
515 | stable/MAJOR.MINOR. This process is not held up unless a crash or | |
516 | security issue has been found and needs to be addressed. Issues | |
517 | being fixed will not cause a delay. | |
518 | ||
519 | Bug fix releases are at 1 month intervals until next MAJOR.MINOR is | |
520 | pulled. Then at that time as needed for issues filed. | |
521 | ||
522 | Security issues are fixed for 1 year minimum on old releases and | |
523 | normal bug fixes for the current and previous release | |
524 | ||
a03e3526 QY |
525 | ### Miscellaneous |
526 | ||
527 | When in doubt, follow the guidelines in the Linux kernel style guide, or ask on | |
528 | the development mailing list / public Slack instance. |