... | ... | @@ -634,7 +634,7 @@ should be resolved using executables they are loaded into. |
|
|
|
|
|
# User Interface (UI) Guidelines
|
|
|
|
|
|
BIND 10 is a server process, so does not have much that would be considered a user interface. This section discusses what we do have.
|
|
|
Kea is a server process, so does not have much that would be considered a user interface. This section discusses what we do have. See [Stork coding guidelines](https://gitlab.isc.org/isc-projects/stork/-/wikis/Processes/coding-guidelines) for UI guidelines for Stork.
|
|
|
|
|
|
## IP address and port formatting
|
|
|
|
... | ... | @@ -652,6 +652,13 @@ For IPv6 addresses, this looks like this: |
|
|
|
|
|
If you import code from another project, try to continue the style of the imported project if changes need to be made. This is for two reasons, one is to make merging future versions easier. The other is the encouragement of submitting changes upstream.
|
|
|
|
|
|
# Deprecating options
|
|
|
|
|
|
Sometimes we need to introduce changes that are not backward compatible. If possible we try to support the old way while making the new way possible. When introducing new alternative ("new way") that eventually going to replace an existing option ("old way"), there should be at least one stable series which supports both old and new way. If old syntax is used, a warning should be printed urging people to update their syntax.
|
|
|
|
|
|
For example:
|
|
|
The old `reservation-mode` parameter has been replaced with `reservations-global`, `reservations-in-subnet` and `reservations-out-of-pool` in 1.9.2. A warning should be printed if `reservation-mode` is used. Such a warning should be coded as soon as realistically possible to give people as much advance warning as possible. As such, this will be implemented in 1.9.2, so early adopters will see it right way. It will be included in 2.0, where users preferring stable will see it. The old way can be removed somewhere in 2.1.x, so 2.2 will not accept it anymore. This way people who use only stable version will have time to migrate. They'll see the warning when moving from 1.8 to 2.0 and will have time until 2.2.
|
|
|
|
|
|
# Guidelines Adopted by Other Projects
|
|
|
|
|
|
Other projects have their own coding guidelines. Here're some
|
... | ... | |