| ... | ... | @@ -666,6 +666,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.
|
|
|
|
|
|
|
|
Importing code is not a decision that can be taken lightly. Please discuss this on a meeting first. Consider the following aspects:
|
|
|
|
|
|
|
|
- are the license compatible? Will this require adding extra text to `COPYING`? Will this complicate the licensing even further?
|
|
|
|
- what's the update policy should be? Should we keep updating the code every time there's a new upstream release?
|
|
|
|
- why can't we develop the code on our own?
|
|
|
|
- what are the implication for building? Will this import make Kea compilation more complex, especially for people who don't care about the new feature?
|
|
|
|
|
|
|
|
# Deprecating features
|
|
|
|
|
|
|
|
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.
|
| ... | ... | |
