search

vegastrike / Vega-Strike-Engine-Source

Vega Strike Engine
Other
255 stars 42 forks source link

Release Plan #76

Open nabaco opened 4 years ago

nabaco commented 4 years ago

I think it'd be nice if we make a release plan. e.g. decide what are the upcoming releases, set milestones, etc.

For starters, I suggest that the next release will be 0.6.0 which will include:

This way, we'll supply up to date binaries for players to use, so we will begin receiving relevant feedback from users.

@vegastrike/code-developers

BenjamenMeyer commented 4 years ago

@nabaco agreed. We can use Git Hub Milestones to track to a given release. Not sure if we want a project board for releases too; Milestones are probably sufficient.

Before we start doing any major refactoring work; it'd be nice to do a small release to just show we can do a release; minimal changes mostly focused around compilation:

We might do just a single release that way (0.6.0) and then start a major refactor for another release series (0.7.0).

Thoughts?

nabaco commented 4 years ago

In that case, we might want to branch out to 0.6.x immediatly, since the refactoring is on the way already. I thought 0.5.3 was supposed to be the small release, but maybe I'm missing something. If you want to branch out now, I guess you should do it from the commit before #57 was merged - since that is the beginning of the big refactors.

BenjamenMeyer commented 4 years ago

is what is in there now able to be released? I'm not opposed to having a big refactor in 0.6.0 if it's necessary to build the release; just thinking we need to limit what we do for 0.6.0.

nabaco commented 4 years ago

is what is in there now able to be released?

That depends. I think we need to define first the acceptance criteria for the release. Are linux binaries enough? Just the source code?

I inclined towards a source code tarball, and would strive to complete #50 as a milestone for the release.

BenjamenMeyer commented 4 years ago

Per requirements for a release - source + binaries would be good; same as previous releases. If we do 0.6.0 as only Linux, then we should follow up with 0.6.1 and perhaps 0.6.2 with Windows and Mac too if we can.

If no one has a system to test those on, then we won't be able to release them and that may be okay - we just have to put out a call for more volunteers to help with testing that if folks want to help resurrect that side of the system. We'll try not to break those; but can't guarantee it without someone testing them. Once we get to doing unit tests it'll be easier to bring them back up.

Given that I've heard folks talk Mac and Linux I think we can target those two for 0.6.0 even if we let Windows slide a bit.

nabaco commented 4 years ago

That sound good. I'll begin with the milestones. We'll more, according to feedback from the rest of the guys

nabaco commented 4 years ago

I've created a "0.6.x Release" Milestone, and added some issues to it. The problem is, unlike projects, it's per repo, and not per organization. I think projects might be a better way to organize this.

BenjamenMeyer commented 4 years ago

Yeah. I'm aware milestone are per repo. I do think that's an issue either right now as we're just releasing the engine. Most of the repos aren't involved in a release, and the asset repos would be their own game as a release.

Thanks!

royfalk commented 4 years ago

I’m fine with it. Just so you know, I made an initial slash of the network code and fixed everything and it compiles. However, I’m eating hay, trying to figure out a segmentation fault that cropped up. If I don’t figure it out today, I’ll try and push it like this and maybe someone else can take a look.

From: Benjamen Meyer notifications@github.com Reply-To: vegastrike/Vega-Strike-Engine-Source reply@reply.github.com Date: Wednesday, 22 April 2020 at 4:50 To: vegastrike/Vega-Strike-Engine-Source Vega-Strike-Engine-Source@noreply.github.com Cc: Roy Falk roy@falk.co.il, Team mention team_mention@noreply.github.com Subject: Re: [vegastrike/Vega-Strike-Engine-Source] Release Plan (#76)

Yeah. I'm aware milestone are per repo. I do think that's an issue either right now as we're just releasing the engine. Most of the repos aren't involved in a release, and the asset repos would be their own game as a release.

Thanks!

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHubhttps://github.com/vegastrike/Vega-Strike-Engine-Source/issues/76#issuecomment-617497366, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACQWBEFMDSGTZMROG2RPFVDRNZEP5ANCNFSM4MNSYVTA.

stephengtuggy commented 4 years ago

Just from personal experience... getting Windows building again is going to be WAY too much work for 0.6.0. Let's push that out to 0.6.1 or 0.6.2/0.6.x.

Other than that, what you guys have listed here looks pretty good.

nabaco commented 4 years ago

Hi @BenjamenMeyer @evertvorster @stephengtuggy @Loki1950, In light of @evertvorster's activity in the Assets repository, and his confidence with the Py3 engine, I think we can move the discussion to here from the Gitter chat/other issues.

The initial plan was:

This plan was an initial one that was supposed to give us a safe roadmap for the near future until we get more confident with the code, and get more people into the project.

But it doesn't mean we can't be flexible enough to reconsider this release plan. Furthermore, as much as we need to think about the near future, we do need to think long term, and take our end-user's experience into consideration too.

Some points to consider:

I think the main reason we decided to have as least changes as possible on the 0.6.0 branch, was not because we wanted to release "stale" code, just for the sake of a release, but because we wanted to have a strong and stable release. So my question to the audience is, if we are confident that the Py3 engine is stable, why not release it?

Bottom line, my offer is, let's give this a shot. We don't have to decide immediately. Let's test the Py3 engine on the 0.6.x, all of us, together, and come to a decision whether it is a releasable product based on concrete information, and not just on our fears and assumptions.

BenjamenMeyer commented 4 years ago

@nabaco actually the point of the 0.6.x Branch is closer to a stale release to we can show we can release and have something relatively close to the last release by the last group of maintainers. This gives a cut point and the ability to point where something was broken - historical broke or we broke it. This also allows us to focus on just the release process itself and any changes we need to make that happen. Since then we've allowed a few bug fixes in based, but I'd really like to keep that minimal. With 0.7.x (current master) and later we can open the doors.

As to save files.. that is already the case. No matter what we do we will need a converter.

BenjamenMeyer commented 4 years ago

@nabaco that's not to say that we won't be flexible.. I stated up front that we might be able to drop 0.8.x if we found that everything was working in 0.7.x.

That said, the more I think about it the more I'm thinking we'll need a release that will support both Py2 and Py3 before we drop Py3 entirely, which is a normal method of doing upgrades of this nature. We can make that 0.7.x and then completely drop Py2 in 0.8.x.

evertvorster commented 4 years ago

Thanks for this detailed discussion. I have read through it, and I would like to comment:

The second you hit the branch to 0.6.0, you did a soft release. When the AUR packages hit, you already have at least one user of the 0.6.0 branch, release or not. My boys love the game, too, and have started playing it. The process of making the better game better is intriguing to them. We test the hell out of Vega Strike. Anything issues that pop up we fix and send back.

From my experience as a gamer, the game is stable enough to release now, just pull the trigger and compile the 0.6.0 packages already!

If you want there to be no load errors, I will be working on those tomorrow through my inevitable hangover of my b/day party.

XD

Once you gain confidence in my fixes, release 0.6.1 with them in. Easy win for everyone, and you guys can concentrate on making a solid plan on where we are going to take the engine. Is there still any talk of replacing it? It seems a shame, as engines go, this one is pretty solid. I think for 0.6.1 the goal should be a silent console, and no in-game load errors. Even if the code is in chaos, if the debug switch is not turned on, the game should not display anything that did not kill it. I might even be tempted to go look up how such a thing is done and start to implement it.

How hard can Python be?

BenjamenMeyer commented 4 years ago

@evertvorster there's a lot of documentation, infrastructure stuff that needs to be done (mailing list setup, etc) so we can injest bug reports, etc. Presently I think only devs will bother reporting something to us. I'll have to link in some more stories to the 0.6.x project board.

I only anticipate having 0.6.1 if we get Mac or Windows compiling there. A change like Py2 to Py3 is certainly a bigger release than 0.6.0 to 0.6.1, so please let's keep that stuff on master.

As to the engine...yes we have an issue discussing the engine tech (#72) however I don't see us doing anything other than enhancing what is here. We're certainly not going to change it out as that is what Vega Strike itself is - a game engine. We may, however, change out some of the rendering functionality (#46) in order to update to more modern graphics APis, but the engine itself will remain true to what it is.

evertvorster commented 4 years ago

@BenjamenMeyer, I agree, let's fix what we have first, before breaking it in dev.

0.7.x would be a natural fit for Python 3 only as a development branch, and when it is done, you have a stable 0.8.0 that is Python 3 only.

Let's support Python2 through 0.6.0. - 0.6.n, but then call it a day for Python2. Even numbered branches are supposed be stable, and left alone in it's golden old age of stability.

The only reason I am playing Python3 version of 0.6.0 is because the "jumping" bug in 0.7.0 and master makes the game un-playable. 0.6.0 is the only branch that has a fix for it. Once there is a fix for the jumping bug in 0.7.0 I will jump to development branch and leave stable in peace.

I have the type of system available to me that can do a pretty good test of any crazy ideas on 0.7.0. My save file was started on Python3, so that is naturally what I would like to test upon. This is my vote of confidence that Python3 is already ready enough for wide scale testing.

Bill Gates said release early, release often. He is not doing too badly himself now, that that might be sage advice.

TL;DR I'm willing to support it through 0.7.x with testing from my side.

stephengtuggy commented 4 years ago

@nabaco actually the point of the 0.6.x Branch is closer to a stale release to we can show we can release and have something relatively close to the last release by the last group of maintainers. This gives a cut point and the ability to point where something was broken - historical broke or we broke it. This also allows us to focus on just the release process itself and any changes we need to make that happen. Since then we've allowed a few bug fixes in based, but I'd really like to keep that minimal. With 0.7.x (current master) and later we can open the doors.

As to save files.. that is already the case. No matter what we do we will need a converter.

I agree with this. FWIW, I have about 2 GB of old save files lying around. :-)

Can we release 0.6.0 now? I.e. by the end of the week, as source code only? Then shift our attention to 0.7.x, and fix the jumping bug ASAP?

Heck, don't we already know how to fix the jumping bug? Or at least something we can try?

I would be OK with planning to finish the Py2 to Py3 upgrade in 0.7.x. I've done this transition before, on another project. It's a bit of a process, sure, but not that bad. Mostly, you just have to be thorough -- in reviewing the code; in making any changes needed; and in testing. This will require some time. And it will require multiple eyes on things.

But I could see us finishing the Python 3 upgrade in a couple of months or less.

What do you guys think?

BenjamenMeyer commented 4 years ago

@stephengtuggy doing a source only release is certainly an option. https://github.com/orgs/vegastrike/projects/7 outlines the stuff to get done for the release. I'll try to vet that tonight again; we can probably accomplish most of that within a week or two.

We already have Deb files and tarballs able to be generated. We can generate RPMs too but no one has setup the dependencies. I think Mac packages are also possible, though our Mac build isn't really working; same for Windows. (#131)

So really the big tasks are:

We need to check on:

evertvorster commented 4 years ago

@stephengtuggy I can give you a list of link requirements from my system. Chances are the package names will map across to Debian and RedHat

evertvorster commented 4 years ago

My feeling on when to release is this: I have been playing on a version of Vega Strike that is stable and pretty enough to keep me entertained for at least that week. It's criminal to withhold something this good from the rest of the world a second longer.

BenjamenMeyer commented 4 years ago

@evertvorster Unfortunately package names don't map well between Debian and RPM systems. They use two different naming conventions. Even between Red Hat and SuSE - both RPM-based - have some differences and aren't necessarily compatible so you can't always drop a RPM from one on a system for the other.

You can see what we currently have documented for dependencies in the CMakeLists.txt file: https://github.com/vegastrike/Vega-Strike-Engine-Source/blob/master/engine/CMakeLists.txt#L1157

https://github.com/vegastrike/Vega-Strike-Engine-Source/blob/master/sh/vspackage.sh#L41 needs to be fixed up for RPM-based systems and then the same logic as used on Debian can be used.

evertvorster commented 4 years ago

In regards with releases: It might be a wonderful idea to do a source only release, with a promise of binaries in the near future.

There are two obvious benefits to a source release.

  1. It allows you to release now.
  2. It may get some packagers for the platforms that need packaging to take notice and pop over to give you a hand with the packaging for their chosen platform. They might even host the packages for you, and integrate it into the official package repos.

I find it weird that you are making the .deb and .rpm in any case. Not many projects do this. I'm new here, so the reason for doing it this way might become clear to me later.

Same with the install scripts. Not many system admins will run a script off the internet with root privileges. Even with multiple backups, I find it a scary prospect.

If you can do a nice clean cmake, make & make install on the source, then packaging it is no problem for any package maintainer. This is traditionally also the end of the responsibility for the creators of the software.

Anyways, I suppose it's starting to be time to make some noise on the internet about the upcoming release, and get people salivating... or at the very least, inquisitive. On THAT front, any eye candy that I post with Vega Strike in it is automatically yours to do with as you please, should you want to re-use it for something else.

BenjamenMeyer commented 4 years ago

@evertvorster and yet AnyConnect, Docker, and a number of other popular tools install via a script off the internet with the install instructions being:

$ curl .... | sudo -

Always amazes me how many folks will do that.

We are building the packages because it's the right thing to do and the correct way to install stuff. I personal package all my software and look to get it in proper distribution channels.

I also try to avoid the above in favor of using a verifiable repository.

Loki1950 commented 4 years ago

If we are releasing packages we had better get a way of signing our packages as exclusively ours.We need a digital signature.This should also allow us to develop a level of trust with users and package maintainers.

BenjamenMeyer commented 4 years ago

@Loki1950 yes; RPM and DEB use GPG keys so we can easily do that.

BenjamenMeyer commented 3 years ago

We've completed this well enough for 0.6.x; moving future work to 0.7.x.

BenjamenMeyer commented 3 years ago

We should be good for 0.7.x; moving to 0.9.x for anything remaining as we want to get 0.7.x and 0.8.x out the door quickly.