- Joined
- Sep 4, 2013
- Messages
- 1,477
- Reaction score
- 1,617
Last Updated: 07/05/2017
This is a work in progress, the release cycle is subject to change. We still have a couple of areas to decide on.
This is our release cycle; this document describes how development works to achieve a new release, detailing different stages of a release/build cycle. We no longer run on a set release schedule (in the past, we released every 2 weeks); instead, we follow a set of rules and parameters to decide whether a dev build becomes a pre, and a pre build becomes a release. Because we now no longer run on a set schedule for release, we think it's important that instead, we have a set schedule for news. Even though we might not be releasing, it's still important to keep our community up to date on where we are.
Why do we do this?
What are build types?
Build types are the different stages of development a version goes through. All development work begins in the dev build. In dev builds, we (Schine) likely have not gone through any testing procedures. Generally, they have incomplete additions, removals and fixes. Once a dev build is "feature complete" has been tested and meets all pre build parameters, it's sent to the pre build branch. Pre builds are fairly safe, ready for general user testing e.g. servers and users. Once a pre build has met release parameters, we send it to the release branch, ready to be used by everyone.
Here's a basic development flow of build types:
Feature Development -> Dev build -> Fix bugs in new features -> Fix existing bugs (fewer bugs than the last release) -> Pre-release (Release Candidate) -> Fix new bugs affecting pre-release (focus on release blockers, major and high priority bugs) -> Release
Different types of builds:
Dev build - is an unstable, incomplete "use at your own risk" build, dangerous and can harm content, NEVER use in a production environment.
Pre build - is our release candidate, they are in a state where we think they're safe and stable. However, they still need to be tested by a wide range of users/servers, to ensure nothing was missed in previous testing procedures. We don't recommend using pre-builds in production or for normal gameplay; we do encourage everyone to try them out and help us make sure they're ready for release. Servers should setup copies on them to test their database and updates, if any issues are found, please make sure to send a report to us. We'll address it as soon as possible.
Release build - should be stable, safe to use. Has been validated by the testing team and other servers participating in the pre-release program.
How does a dev build become a pre build?
(WIP) Once a dev build has had all content additions/modifications/removals completed, it is ready to go through pre-build testing. Once pre build parameters are met, the build can then be switched to the pre branch.
The following parameters must be met before switching from dev to pre build:
How does a pre build become a release build?
Release builds are all about stability and functionality. We must ensure that release builds are free from serious issues and feature additions are working as intended. If this is not met, user data can be damaged or completely lost, so it's imperative that we get it right. For these reasons, pre builds have no defined time for when they become a release build. We have no deadlines for releases, instead, they must meet a set of parameters before becoming a release build. If these parameters are not met, we will not release.
The following parameters must be met before switching from pre to release build:
Pre-release (Release Candidate) -> Fix new bugs affecting pre-release (focus on release blockers, major and high priority bugs) -> Repeat until no more high priority or higher bug reports -> All parameters met -> Release
Not completely accurate, misses a few steps, gives the basic idea.
When do we release news posts, and what should we expect to see?
We schedule to have a news post out every week. Some weeks we might skip, but we'll give heads up on our social What this will contain is a recap of what we've been working on for the past week and potentially, what our focus is for the upcoming weeks. For longer term work (like the NPC update), the content we worked on in the current week, might be the same as the previous. In that case, we'd likely speak about future plans, goals, or even go into detail about the development of a previous feature.
Are news posts scheduled to come out on a specific day?
No. We schedule to have a news post every week, but it could be ready any day of that week. We try to finalise the drafts of our news posts at our weekly team meeting on a Sunday (UTC). So, very often, they'll come out at around that time.
This is a work in progress, the release cycle is subject to change. We still have a couple of areas to decide on.
This is our release cycle; this document describes how development works to achieve a new release, detailing different stages of a release/build cycle. We no longer run on a set release schedule (in the past, we released every 2 weeks); instead, we follow a set of rules and parameters to decide whether a dev build becomes a pre, and a pre build becomes a release. Because we now no longer run on a set schedule for release, we think it's important that instead, we have a set schedule for news. Even though we might not be releasing, it's still important to keep our community up to date on where we are.
Why do we do this?
- Put out more stable releases (practically free from major game breaking bugs, some will always slip through, but we won't release with known major issues).
- Every release is aimed to have "fewer bugs than the last", what this means is that every release cycle should have fewer bugs in the Phabricator bug tracker queue than the last.
- Speed up development, a big slowdown in development from the last release cycle schedule was that we were constantly hotfixing our releases. Hotfixes would eat into the next release cycle's dev time, giving us even less time to develop and test. The new system will allow us to take things at our own pace. Although there will be fewer releases, they'll likely be bigger and certainly more stable. The number of releases does not indicate how fast development is going; fewer releases doesn't mean we're slowing down, it should, in fact, mean we're speeding up.
- Allow us to work on larger releases. 2 weeks isn't enough for a significant gameplay addition, so often we'd have to extend the release cycle anyway. The way we've set our new schedule should allow us to easily work on large features and allow us to push through to the next gameplay addition even when a previous release is still in pre-release status.
What are build types?
Build types are the different stages of development a version goes through. All development work begins in the dev build. In dev builds, we (Schine) likely have not gone through any testing procedures. Generally, they have incomplete additions, removals and fixes. Once a dev build is "feature complete" has been tested and meets all pre build parameters, it's sent to the pre build branch. Pre builds are fairly safe, ready for general user testing e.g. servers and users. Once a pre build has met release parameters, we send it to the release branch, ready to be used by everyone.
Here's a basic development flow of build types:
Feature Development -> Dev build -> Fix bugs in new features -> Fix existing bugs (fewer bugs than the last release) -> Pre-release (Release Candidate) -> Fix new bugs affecting pre-release (focus on release blockers, major and high priority bugs) -> Release
Different types of builds:
Dev build - is an unstable, incomplete "use at your own risk" build, dangerous and can harm content, NEVER use in a production environment.
Pre build - is our release candidate, they are in a state where we think they're safe and stable. However, they still need to be tested by a wide range of users/servers, to ensure nothing was missed in previous testing procedures. We don't recommend using pre-builds in production or for normal gameplay; we do encourage everyone to try them out and help us make sure they're ready for release. Servers should setup copies on them to test their database and updates, if any issues are found, please make sure to send a report to us. We'll address it as soon as possible.
Release build - should be stable, safe to use. Has been validated by the testing team and other servers participating in the pre-release program.
How does a dev build become a pre build?
(WIP) Once a dev build has had all content additions/modifications/removals completed, it is ready to go through pre-build testing. Once pre build parameters are met, the build can then be switched to the pre branch.
The following parameters must be met before switching from dev to pre build:
- Has been tested on the testserver for startup issues or early crashes.
- Minimum testing period of 24 hours.
- Testing team approval.
How does a pre build become a release build?
Release builds are all about stability and functionality. We must ensure that release builds are free from serious issues and feature additions are working as intended. If this is not met, user data can be damaged or completely lost, so it's imperative that we get it right. For these reasons, pre builds have no defined time for when they become a release build. We have no deadlines for releases, instead, they must meet a set of parameters before becoming a release build. If these parameters are not met, we will not release.
The following parameters must be met before switching from pre to release build:
- All bugs with a priority over high have been fixed.
- Pre-release news post has been made. Call for testing locally and on our test servers.
- Call for participating server owners to test pre-release versions on a mirror copy.
- Testing team approval.
- Less documented bugs on Phabricator than the last.
- 5 days since a high priority bug or higher has been reported since last pre-release.
Pre-release (Release Candidate) -> Fix new bugs affecting pre-release (focus on release blockers, major and high priority bugs) -> Repeat until no more high priority or higher bug reports -> All parameters met -> Release
Not completely accurate, misses a few steps, gives the basic idea.
When do we release news posts, and what should we expect to see?
We schedule to have a news post out every week. Some weeks we might skip, but we'll give heads up on our social What this will contain is a recap of what we've been working on for the past week and potentially, what our focus is for the upcoming weeks. For longer term work (like the NPC update), the content we worked on in the current week, might be the same as the previous. In that case, we'd likely speak about future plans, goals, or even go into detail about the development of a previous feature.
Are news posts scheduled to come out on a specific day?
No. We schedule to have a news post every week, but it could be ready any day of that week. We try to finalise the drafts of our news posts at our weekly team meeting on a Sunday (UTC). So, very often, they'll come out at around that time.
- [07/05/2017] - Added details to the "Are news posts scheduled to come out on a specific day?" . News posts are scheduled to come out every week, sometime after or on Sunday (UTC) [Diff Checker]
Last edited:
