How We Release New Features
Our app team works in three-week development sprints. As Halgari explains, this is a little unusual in software development, where two-week sprints are more common. We’ve found that three weeks gives the team the right balance, as it gives enough time to work on meaningful features without needing to rush or constantly split things up into smaller tasks.
At the end of each sprint, we prepare a new build of the app. Sometimes, that means releasing a feature in full. Other times, we might only include the back-end code and hold off on the user interface until a future version. In some cases, a feature might be technically included in a development build but hidden from view using a feature flag, so it does not appear in the public release until we are ready.
Once the sprint ends, we hand the build over to our QA testers. They run it through its paces on lots of different systems, test it with various games, install collections and mods, and check everything behaves as it should. If anything is broken or not working as expected, they let us know, and the team fixes those issues before we ship it.
Sometimes we will leave a minor issue in place if it is not likely to affect most users, but if a new feature breaks something that used to work, that is a big deal, and we will always aim to fix it before releasing.
Once QA is complete, we push the update live. All in all, that means there is usually a gap of around four and a half weeks between a feature being completed and it appearing in a public release. That includes three weeks of development and about a week and a half of testing.
Now, if we get feedback from you, for example, a feature is not working quite right or there is something you really want changed, there are a few steps before we can act on it. First, we need to break down what needs doing, figure out how to approach it, and decide who on the team is the best fit for the task. But most of the time, our developers are already mid-sprint, working on something else. Asking them to switch focus comes with a cost. In software development, switching tasks often means losing momentum, so we try to avoid pulling people away from their current work unless it is really urgent.
So once the task is scoped and assigned, it might take another sprint cycle before someone can start on it, and then another three weeks to build it out, followed by QA. That means even if we agree with a change straight away, it could still take up to two months before you see it in the app.
We would love to be able to fix everything instantly, but the reality is that development takes coordination and planning. Everyone on the team is working hard, and the more we rush or react without a plan, the slower the whole process becomes.
Understanding Version Numbers
We’re still in beta, which means the first number in each version will remain zero for the time being. The second number goes up with each sprint. At the time of filming, version 0.11.3 was publicly available, version 0.12 was in testing, and version 0.13 was in active development. The final number indicates the build number, which gives you a rough idea of how many times it was returned to the team during testing or whether a hotfix was added after release.
Feedback We’re Acting On
We’ve received a lot of feedback lately on two key things: support for modding games through the Epic Games Store and allowing users to choose where their mod files are stored.
First, Epic Games Store support. Until recently, we weren’t aware Cyberpunk 2077 was even available on the Epic platform. Once that came to light, we started exploring what was needed to support it. While the number of users on Epic is relatively small compared to Steam or GOG, it still represents a significant number of people. Work on this is about halfway done, and we hope to include it in an upcoming release. Halgari is personally leading this one.
The second piece of feedback relates to mod storage. Currently, the app only allows mods to be stored in your AppData folder. While the system was built to be configurable, a bug in the code meant it would only accept paths on the C: drive, which understandably caused frustration. The bug has now been fixed, and the team is working on adding a UI option so you can choose your preferred location. While this change won’t be included in version 0.12, the plan is to have it ready for 0.13.
What’s Next?
Here’s some of the upcoming features the team is working on:
- Further progress on collection creation and curation.
- Continued improvements to mod updates.
- Ongoing support for Baldur’s Gate 3.
- Epic Games Store support.
- Custom mod storage locations.
As always, we really appreciate your feedback and support. We’ll be back next month with another update!
12 comments
Its incredibly exciting that so many of you are getting involved and trying the app.
If your sprints work best with that shape, then it's the right choice for the team doing the work ❤️
Good to hear you're making progress too.
https://nexus-mods.github.io/NexusMods.App/users/gettingstarted/MovingToTheApp/