Major releases will be cut and published here for the public to download. We view major releases as software that has been thoroughly tested against multiple machine builds and different configurations. Major releases will be supported until superseded by the next major release. Example: 3.0
Alpha: New and Exciting Stuff
Alpha builds are expected to be buggy and unreliable for production environments. Major and minor bugs are considered normal. Alpha builds are expected to be the place for rapid development of new features, major changes to code and data structures, and a general state of constant flux. Alpha builds will be in the ‘dev’ branch in our git repo. Alpha software is where new feature request that have been approved for this release are coded, and new suggestions will still be adopted. Example: 3.0a
Beta: Feature Freeze
Beta builds are a place where refactoring and code is organized and put closer to a production format. Minor bugs are expected, with Major bugs being rare. Beta builds are not considered production quality, but are a great state for beta testing and reporting of bugs. Beta software will be in the ‘beta’ branch of our git repo. Beta software is where new feature request are cut off from being considered to be added. New features can still be requested, but will only be approved for future versions. Example: 3.0b
RC: Release Candidate
RC builds are considered mostly complete and ready to deploy to your test environment. Major and minor bugs should be squashed or slated for patching soon. RC code is considered stable as well as data structures in the database. RC builds will be tested for at least 2 weeks before being ready to be a release. RC code will be in the master branch of our git repo. RC build numbers will increase every patch or bug squash until no bugs are reported for 2 weeks. RC builds can not go into a Major release until bug free for a minimum of 2 weeks. Example: 3.0RC.1
Major releases: Production Time
Major releases are considered stable and ready for a production environment. Major releases are expected to be bug free. If a bug is found in a major releases, a minor version will be cut to fix this bug, and only change what is required to fix the bug. Major Example releases are in our master branch of the git repo. Example: 3.0
Minor Releases: Oopsie
In the event a bug is found and patched, a minor release will be cut to patch the bug. A minor release number would be 3.0.1.
Development Snapshots: Read Only Fridays!
Development Snapshots will be released on Fridays whenever possible with a snapshot of the code “as is”. These are considered potentially buggy, but do give testers a feel where the software is going. Development Snapshots will be released via the web page on the “snapshots” page. Snapshots will follow a very different naming convention since they are not tied to a version. Their number will be the year followed by the week number. Example: 19w42-snapshot.