Milestone Releases
Before we get too deep into this, there is something we must remind everyone. All three programs are either Beta or Alpha in terms of Development. Think of them like Early Releases on Steam.
With that said we want to address our existing release framework, which has been traditionally divided into 'Stable' and 'Development' versions. Stable versions, our even-numbered releases, we try to keep free of major issues, while odd-numbered development releases represent ongoing progress and innovation and are more likely to have major issues.
This approach, while providing clear structure in the past, has increasingly become a bottleneck. As time between a “Stable” release and continued development grows, it creates a sharp distinction between “Stable” and “Development” releases. New players often choose the “Stable” version only to find missing features and units they’d seen somewhere (aka a Dev release), They encounter issues already fixed, or ask about features added in a development release, making the “Stable” version look noticeably outdated.
Additionally, the mismatch in Java versions for the 'Dev' releases leads to troubleshooting time for us, disrupting the flow of improvements and bug fixes. When we decide to release a ‘Stable’ version, we pause everything except bug fixes, which can take months, hindering advancements in the programs and making it difficult for outside contributors to join as we force them to wait or only fix bugs, effectively stopping innovation and development (remember the size of the Dev team.)
This structure, initially intended to provide stability and reliability, has impeded our ability to rapidly respond to new ideas, player feedback, and technological advancements, resulting in delays and missed opportunities for timely enhancements.
In the past, we relied on the forums and bug trackers for issue reporting. Since moving to GitHub, we have been using integrated tools like nightly builds and GitHub for efficient code testing and review. These checks reduce the amount of game breaking bugs entering the programs. If they do anyway, Discord has emerged as a vital channel for instant player feedback, allowing for a more engaged and responsive development process. This means the difference between the “Stable” versions and the “Dev” versions in actual stability is not sufficient to warrant the time to keep both separate.
To better serve our players and the development team, we are transitioning away from the traditional ‘Stable’ / ‘Development’ labeling scheme to a more dynamic ‘Milestone’ system.
- End of Traditional ‘Stable’ Releases: The ‘Stable’ releases, as we know them, will be discontinued. The next major release anticipated to be labeled as ‘Stable’ will be version 1.0, slated for release before the end of this century. This change signifies a move towards a more fluid and ongoing development process.
- Development Tag for All Releases: Moving forward, every release will be tagged on release as ‘Development’.
- Version Numbering: The specific version numbering, such as 0.49.x or 0.51.x, is determined by the development team based on internal criteria that reflect our ongoing development efforts. Any changes in version numbering will be communicated in the release notes of the respective release. It’s important to note that an even-numbered release will no longer indicates a ‘Stable’ release but simply a change in version numbering. For example, transitioning from 0.49.x to 0.50.x does not signify a move to a stable release but indicates that we have determined that we’ve hit a milestone that warrant the version number change, and both remain development releases.
- Transparent Communication on Significant Changes: As part of our commitment to clarity and user support, any major changes, especially those pertaining to software requirements, will be clearly outlined. For example, changes in the required version of Java, like our previous transition from Java 8 to Java 11, will be communicated in advance. This ensures our users are well-informed and can prepare for any significant updates, such as a future move to another Java LTS version.
Under the new system, our approach to versioning and release designation will be as follows:
- A Development Release: Versions will be labeled as 0.XX.X-Dev and will be released as part of our regular development cycle.
- Observation Period: Post-release we monitor the software’s performance and gather user feedback. This will be from issues opened on GitHub, Discord, social media, etc.
- Milestone Tagging: If a version, like 0.49.7, proves stable and reliable for a period of a few weeks, we will retroactively designate it as a ‘Milestone’ (e.g., 0.49.7-MILESTONE).
- Communication: This designation will be communicated across all our platforms, including release notes, social media, and forums.
The decision to designate a release as a ‘Milestone’ depends on several factors:
- Stability and Reliability: A release must demonstrate a high level of stability and reliability during the observation period.
- Nature of Updates: Releases focused primarily on bug fixes are more likely to achieve ‘Milestone’ status than those introducing major new features or significant changes, like Large Naval Craft, Mobile Structures, or Space to Surface play (not saying we are implementing those anytime soon!).
- Frequency of Milestones: We anticipate MILESTONES will come up every 6-9 months. However, this could be longer or shorter depending on what is happening with development.
To illustrate, consider the following sequence of releases:
- 0.49.7-Dev: Met the criteria for stability and reliability, so we would name it 0.49.7-MILESTONE.
- 0.49.8-Dev to 0.49.17-Dev: Each had issues or aspects of 'weirdness’ and did not meet 'Milestone' criteria. For example, 0.49.15-Dev contained a significant bug, albeit with an easy workaround, but was not good enough to be called a MILESTONE.
- 0.49.18-Dev: If it meets the criteria for stability and reliability, it becomes 0.49.18-MILESTONE (hypothetically) a few weeks after release.
This sequence demonstrates our revised approach; not every development release becomes a 'Milestone' after a week. The designation is reserved for those versions that genuinely meet our standards for stability and user experience. They provide a good entry point to the programs, and a safe release for players to use while waiting on the next MILESTONE. We will encourage players to move up as MILESTONES are released. With the caveat of always keeping backups of your CPNX file, as the programs are still in development (Beta/Alpha/Early Access 😊)
Adopting the Milestone system serves multiple purposes:
- Continuous Development: This approach allows for uninterrupted innovation and improvement in the software. By focusing on the most recent releases, we can maintain a steady pace of development.
- Current Versions for Users: We want to encourage players to move beyond using a 'Stable' version, like 0.48, for extended periods. This approach bridges the gap between Stable and Development versions, enabling players to stay up-to-date more quickly by transitioning between milestones and allowing us to phase out older releases.
- Changing Perceptions: It shifts the mindset from viewing 'Stable' versions as inherently superior to 'Development' versions. This helps foster an understanding that the programs are in continuous development and will remain so for the foreseeable future.
Depends on your definition of risky, the 0.48.0 Stable still had some nasty bugs in it (Skill settings in MekHQ and DFA bugs), but communication and player feedback allowed players to use it knowing the workarounds. Which when you think about it is effectively the same thing we will be doing with MILESTONES, and we have been doing for years with players living in the Development cycle releases.
With the introduction of the Milestone system in the MegaMek suite, we're making a strategic shift towards a more agile and user-focused development cycle. This change is designed to speed up our innovation while also providing our community with access to stable and reliable versions of the software more consistently.