Top Level Plan: 1.0 Release!

[markmandel]

This is a top level ticket for planning out what is required to be in a 1.0 release, keeping in mind that we want to release 1.0 at some point this year.

This is a sacrificial draft of how to manage the process. Please feel free to provide alternate opinions.

Breaking this down into two areas:

Timeliine

Goal is to hit 1.0 in 2019. The earlier, the better.

Functionality

I think the easiest way to track what we feel should be in the 1.0 release should be added as an item in the next upcoming milestone release. If a issue should be added / removed - we can discuss it individually on each ticket.

There is is already a set of issues targeting the next release, for a sacrificial draft of what should be included.

I want to make sure we have a clear plan, but also flexibility to add extra features if we find things that are missing.

Hardening / Scalability testing

TL;DR: Lots and lots of load tests, let's see where it breaks. Fix it once it breaks. Repeat.

Much of this is covered in Load testing ticket.

Question at this point: What are our target goals for gameserver fleet / kubernetes size? What do we determine is "success"?

@jkowalski , @ilkercelikyilmaz , @pm7h - I figure you have thoughts here, since you are doing most of this work.

[markmandel]

/cc @thisisnotapril and @roberthbailey for your extensive experience in this area. Thoughts and feeling much appreciated.

[roberthbailey]

It's also reasonable to say that agones is production ready at a smaller scale than we anticipate eventually supporting. As long as we are clear about what scale is supported (and provide api compatibility) we can make continuous performance and scalability improvements past the 1.0 milestone.

[markmandel]

It's also reasonable to say that agones is production ready at a smaller scale than we anticipate eventually supporting. As long as we are clear about what scale is supported (and provide api compatibility) we can make continuous performance and scalability improvements past the 1.0 milestone.

100% agree. So I would rewrite the above to be:

Once 1.0 features are complete, performance testing will be completed, and the project will publish supported cluster sizes, fleet sizes and throughput metrics based on the current code base.

Works for me. Work for everyone else?

[markmandel]

Added a note about schedule, since it keeps coming up

[markmandel]

0.11 ➡️ 0.12

• Ideally all breaking changes and features will be implemented before the 0.12 release
• This essentially becomes a release candidate, and we go into feature freeze at this point.

0.12 ➡️ 0.13

• Time between 0.12 and 0.13 would then be spent writing more tests, docs, performance testing, etc

0.13

• This would be the actual 1.0 release.

Risks

• We don't actually get all the functionality in in time for 0.12
• There is missing functionality in some of the SDKs, some of which we will need to source technical capability for
• There are outstanding issues around how to test Unity and/or Unreal because licencing.
• Load testing. Unknown on how we want to do this???
• With all the breaking changes, do we need to document/determine upgrade paths

[markmandel]

Since we're doing the RC for 1.0, I figure this should get closed with the stable release.

Any objections?

[roberthbailey]

sgtm

[markmandel]

🌟 CLOSING 🌟