Release process changes
Re: Release process changes
Please, feel free to continue your discussion -- but I've just created another thread to keep track of the discussion's results as well as write down the new release process.
Re: Release process changes
I think most of this has been discussed into oblivion at this point, but I think I'm not understanding exactly the purpose of the RC phase.
I completely agree that RC threads should be separate from the project release thread. It normally works, but if we have to have any discussion about the separate RCs at all it quickly devolves into a barely tolerable mess, hence why I didn't want to add a redundant affirmation. What I'm not understanding I think is what are you expecting to get out of RC testing? Because whatever you release will have bugs, even once the release is finalized. It seemed to me that you just needed someone to say "yep, that installer works and I can play the game without anything immediately blowing up." Then that particular package would be ready. If you need more confirmations, making things private seems counterintuitive.raevol wrote: RCs need to either be kept private, or release packages need to be independent of the project release. Why? This is why:And to follow on to that, if you test a release package, PLEASE let us know that it worked, even if someone else already posted it works. We need those confirmations, and the more the better.Ravenwing wrote: I also downloaded the Win 64-bit RC and played it when it was originally posted by Ace, everything worked for the short time I played it, and I think someone had already commented it was fine, so I felt no need to add to anything. But I've been wondering what's going on because our landing page still has 0.39 as the latest blog post.
Re: Release process changes
That's exactly it- RC testing just ensures that the RC package isn't a dud, and includes a runnable build of the code at the release tag.Ravenwing wrote:What I'm not understanding I think is what are you expecting to get out of RC testing? Because whatever you release will have bugs, even once the release is finalized. It seemed to me that you just needed someone to say "yep, that installer works and I can play the game without anything immediately blowing up." Then that particular package would be ready. If you need more confirmations, making things private seems counterintuitive.
Keeping things private didn't have anything to do with testing, it was meant to keep people from misunderstanding that the release was finalized when it wasn't. That's why I said it would take more work if we did go the private route- we would need dedicated testers to ensure the testing actually happened.
I think all of these issues will be solved with the CI system we are discussing now. It will simplify everything, give us ultimate confidence in the release packages, and allow us to not release a "release" until it's actually released, because all we're going is picking a package that's already built and saying "ok it's that one".
- psi29a
- Posts: 5361
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact:
Re: Release process changes
The confusion is probably over the terms used and what people expect.
I had always thought that the RC threads were also testing threads. The problem was that once the tag was set, the same thread was used to post the final builds and links to the video for convenience of those working on the release.
From my point of view, the RC and testing thread(s) remain the same, but the communication over the final builds and video are held just between those that are making the release.
Please correct me if I'm wrong.
I had always thought that the RC threads were also testing threads. The problem was that once the tag was set, the same thread was used to post the final builds and links to the video for convenience of those working on the release.
From my point of view, the RC and testing thread(s) remain the same, but the communication over the final builds and video are held just between those that are making the release.
Please correct me if I'm wrong.
Re: Release process changes
Sorry I've been a little MIA lately, life, etc.
I see our daily PPA is building again. Did we have any success getting windows/mac packages to daily build as well? Sorry I am kind of out of the loop.
I see our daily PPA is building again. Did we have any success getting windows/mac packages to daily build as well? Sorry I am kind of out of the loop.
Re: Release process changes
On the windows side, well;
https://github.com/OpenMW/openmw/pull/1065
And the build itself
https://ci.appveyor.com/project/scrawl/openmw/build/563
Takes almost two hours to run through, but it seems to mostly work.
https://github.com/OpenMW/openmw/pull/1065
And the build itself
https://ci.appveyor.com/project/scrawl/openmw/build/563
Takes almost two hours to run through, but it seems to mostly work.
Re: Release process changes
Is it downloadable?
Re: Release process changes
Well, I recall being able to download and run them, yes.
If not then I would've spent more time fixing the whole thing.
Here's the Visual Studio 2013 32-bit artefact for instance;
https://ci.appveyor.com/project/scrawl/ ... /artifacts
If not then I would've spent more time fixing the whole thing.
Here's the Visual Studio 2013 32-bit artefact for instance;
https://ci.appveyor.com/project/scrawl/ ... /artifacts
Re: Release process changes
It seems a little difficult for end-users to find? I feel like I am missing something big here, I apologize!
Re: Release process changes
That was a proof of concept, a test to see if it would be even possible to build runnable game packages inside the AppVeyor time limit.
I think there are ways to use their API and upload the builds to more suitable locations, just haven't looked much into that.
I think there are ways to use their API and upload the builds to more suitable locations, just haven't looked much into that.