Closed JayFoxRox closed 6 years ago
JayFoxRox
commented
8 years ago @rwengine We should have a decision for this soon so we can start working on distribution (and finding package maintainers etc.). It's an important factor in finding more users for OpenRW.
danhedron
commented
8 years ago The incrementing version number is the way I'd like to go. Just using milestones to plan the issues that need to be resolved for each release. We shouldn't plan more than 2 versions into the future just to keep things simple. For the releases, I think each version milestone should focus on:
Since we want "psuedo-nightly" builds, I think that's a reasonable way to balance releasing versus getting wide testing of new features.
This just means we need to figure out how to:
ghost
commented
7 years ago I think most crucial things to do for release are interpolation and better physics.
JayFoxRox
commented
7 years ago That's opening a can of worms @ShFil119 . It's hard to define a threshold of what's good enough (physics wise).
Also it's a very hard task and doesn't quickly allow more gameplay. It's also not productive code-wise: it would boil down to tweaking random numbers for weeks. Consider it some kind of refactor work. While refactors are necessary sometimes, they can also be very hindering for the overall project progress.
Work should be focused on getting more parts to work or removing complicated code. That will attract more people and allow us to focus on these side-issues (actual refactors and tweaking of parameters). However, overall that's a whole different discussion to be had.
This issue is about the release strategy and the thresholds necessary for each feature / metric (e.g. "X runnable missions" / "X supported features of the game" / "Vice City map loading" / ..).
cyphar
commented
6 years ago Having releases means that adding this to distributions will be much easier (nobody likes packages that are just a git commit hash as a version). Personally I really like how OpenMW modelled their release timeline.
danhedron
commented
6 years ago We are now publishing CI artifacts on Windows, this is marginally more helpful for testing.
Exporting actual releases should be done soon. I'm tracking what I think we need to do to get some good initial reception from new users with the first milestone for 0.1.
danhedron
commented
6 years ago My plan is to publish point releases (via GitHub) at least every quarter for the time being, if it becomes possible we can increase the rate. We can refine the criteria for 1.0 as we run out of things that are obviously wrong.
I would like to have nightly artifacts available for macOS and Linux as well, but I can't justify the infrastructure to support that at the moment.
I'll consider this issue resolved for now, once we're shipping we can make adjustments.
We currently have milestones for 1.0 and 0.1; Version 0.1 is extremely close to being complete - there are simply no issues about usability. It’s purely technical. This is bad because version 0.1 wouldn't have to contain anything.
I think we should close the large meta-issues like #1 and #14.
A nightly-build schedule will get us test results quicker and encourages people to compile the latest master. Most distributions also allow git packages these days. We’d still need stable releases for some distros, but those can simply be defined by “X missions” since last release. If we keep the increments in version number small we’ll eventually end up with a clean 1.0 release by doing a jump: e.g. 0.01, 0.02, 0.03, … 0.31, 1.0 (as the main storyline is completable and we consider it feature complete)
Just to clarify: A nightly-build would be automaticly be build for Linux, macOS and Windows on push to master (meaning it's not really a "nightly" release).