Skip to content

Instantly share code, notes, and snippets.

@elifoster
Last active March 25, 2016 22:32
Show Gist options
  • Save elifoster/421ea7885af1924363a4 to your computer and use it in GitHub Desktop.
Save elifoster/421ea7885af1924363a4 to your computer and use it in GitHub Desktop.

Version scheme stays the same: X.Y.Z

Table of Contents

Update updates (X)

Increment when we update to a new Minecraft version, or major Minecraft Forge/Forge Mod Loader version.

Feature updates (Y)

Released at same frequency as they are now: whenever we get enough features.
All features for update Y are developed in a single branch, likely named for example 30 for 0.30 update. This will prevent issues from happening, like in the 0.29 update where features were pushed to master and prevented patch updates until all 0.29 features were done.

Patch updates (Z)

Patch updates are released every 2 weeks containing all of the fixes we come up with during that time. If there are no changes, no release is pushed, but we say in the thread "Sorry, no update this week. We made no progress because we suck" or something. If a feature is merged into master during a patch update phase, then the patch is not released, and instead the feature is released with all of the patches included.

The goals of this new development cycle

  • Consistent release schedule (every 2 weeks on a specific day, perhaps Friday)
  • Frequent patches
  • No more 4 month waiting periods because of messy master branch.

Issues and limitations

  • We have to actually fix the bugs. This is only an issue because we are lazy. In the grand scheme of things, it will benefit us.
  • Xbony2 needs to learn how to use branches. This is also only an issue because he's lazy. In the grand scheme of things, it will benefit him.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment