From Eggdrop Wiki

Jump to: navigation, search


Eggdrop Development Process

Coding Standards

Parens required for if statements

if {

Source Code Management Process

Development Cycle Timelines

Developers should attempt to complete the code updates for a version in 3 months. After this time period, a release candidate should be released with the goal of releasing a stable release 1 month after the first release candidate.

Upon the release of a release candidate, the codebase is considered locked for that version and no changes should be made, except those that directly address a flaw found with a fix/feature added to that specific version, with the exception of critical security vulnerabilities. A bug discovered that existed in previous a version to the release candidate should be documented and addressed in the next version.

Fix/Feature Selection

At the beginning of a development cycle for a version, the 'issues' tab from GitHub is consulted and a number of issues/features are chosen that are expected to take 3 months to complete. These issues are labeled with that version tag in GitHub. These issues/features are the 'baseline' for the version; unless the developers reach additional consensus to modify this list, it is not changed. This list does not prevent developers or contributors from submitting a fix or feature for something not on that list, this list is just the 'blocking' list that states what effort should be focused towards and should be complete prior to releasing that version.

If a new issue is found that is believed should prevent delivering the new version, the developers should reach consensus that it does indeed need to be added to as a version tag in GitHub. If consensus is not reached, this still does not prevent the contributor from working on that feature or fix; it just won't be a blocking issue that prevents the release of the version.


Patchlevel updates take place when one of the tagged issues is resolved. A patchlevel update will increment the previous stable version- in other words, work done on the development for X.Y.Z will show a version of X.Y.(Z-1)+newpatchlevel until a stable release candidate is finalized. Assuming an initial version list showed 12 issues to be resolved for a version, it should be expected to see 12 patchlevel increments during the development cycle. Every submission to the development branch does not require a patchlevel update; they are rather used as milemarkers for people reporting issues with the development snapshot, to give developers an idea about where in the development process the snapshot is from.


Developers: For anything larger than a one line fix (ie, small typos, changing an array size, running autoconf, generating documentation/ChangeLogs, etc), a pull request should be used.

Pull requests addressing a single topic or multiple functionalities should have their PRs squash-merged to the develop branch. Larger feature/fix PRs that are anticipated to have sections reverted or reworked due to the sheer size may be normal merged, but it is suggested to re-baseline in order to consolidate what makes sense (ie, preventing dozens of commits in the history with "fix that one thing" or "change this to that").

A PR should be reviewed by at least one core developer that is not the author. Upon approving the PR, the reviewer should leave a "LGTM" in the comments, indicating it is ready for merging. If, after 48 hours with no issue by other core developers shown, or all developers agree, the PR may be merged in to the develop branch.

Prior to merging a PR, a developer will merge the develop baseline to the PR and then update the patchlevel. The developer will then immediately squash merge back to the develop branch.


To submit a contribution, changes should be submitted via a GitHub pull request. Contributors should only submit code and documentation source file (.rst) edits. Running things like autoconf, version updates, or regenerated txt/HTML documentation should not be part of a pull request.

Personal tools