DCS World 2018 (New Format Stable Version)

Good Day Friends,

It has been said that DCS is always in a perpetual beta state. I had an idea that I would like to propose to EAGLE DYNAMICS: a once yearly stable update. Every year you could release the newly updated engine to the public around the beginning of December, and we can feel comfortable knowing that nothing will change or break for one full year. This doesn't mean that we won't get new content, just that the base game engine won't change.

You could still offer up early access betas for those who want to be parts of the experimental side, of the platform.

This system would probably be most efficient after the 2.5 merge. A good simple formula could look something like this:

August 1st -Internal ED cutoff for new engine features.

October 1st -3rd party cutoff for existing Module updates and patches

October 2nd thru Nov. 30th stability testing

Dec 1st -release new year stable version to the public.

Meanwhile behind the scenes, the following years stable version feature list has already been in work from Aug. 2nd on.

Am I the only one who would like to see a little more stability come to the platform? It seams like every time I Launch DCS, I have to wait for half an hour while new updates are installed, which may or may not work very good. Yes I run the alpha/Beta so I can get the new maps. This is part of the current process I get it. However, I hope in the future that new maps won't require new engine features, and they can just be added as a finished feature complete project.

Essentially instead of getting a 1.5.2 version on the "stable" side it would just be DCS 2018. On the Alpha/Beta side, the version count can evolve just as it does currently. When those cutoff dates come around. The count stops, and only minor hotfixes should be introduced until stable release day comes.

Does this make sense to anybody but me?

Just a thought, Thanks for your time, -Woog

Does this make sense to anybody but me?

Not me.

If you want a stable version for a year, then just quit installing the updates and after a year you can install a years worth of updates. Of course, you also won't be able to use any new modules that are released during that year, but your version will be stable.

Here here!

I've always found it exceptionally weird that ED went against the standard industry norm of one upgrade a year. It would just solve so many problems I don't even know where to start.

While I can appreciate the sentiment, I can't see waiting a year for any fixes or updates. The proposed December update would have the best fixes they have at that time. But that doesn't mean there wouldn't be residual issues and bugs. Any remaining bugs then would not get addressed for a full year? Even if ED has a fix in January for one, they should hold it off till the next December? And there would be no new content for a year?

Seems to me the cure is worse than the disease.

Here here!

 

I've always found it exceptionally weird that ED went against the standard industry norm of one upgrade a year. It would just solve so many problems I don't even know where to start.

That was the old way of doing things. These days, with agile development, an update every month is the norm for a lot of folks.

Probably one of those things that sound better on paper than they would be in practice.

The detail required for simulation pretty much guarantees bugs. And we wouldn't want to wait so long for a fix. That and development in DCS is unpredictable so such a firm schedule might be asking for overlooked problems.

Still an interesting idea though. :)

Not me.

 

If you want a stable version for a year, then just quit installing the updates and after a year you can install a years worth of updates. Of course, you also won't be able to use any new modules that are released during that year, but your version will be stable.

i agree with this. updates are voluntary, dcs always asks if you want to update and you can choose not to. for 1.5 i run only openbeta, but by opting out of most beta updates i can have the best of both worlds.

You could still offer up early access betas for those who want to be parts of the experimental side, of the platform.

if you're looking for a "stable" multiplayer state, then your idea will backfire because of this, as most everyone will opt into this instead for the most up to date fixes -- and it'll be no different than the format we have today.

I've always found it exceptionally weird that ED went against the standard industry norm of one upgrade a year. It would just solve so many problems I don't even know where to start.

Some examples of why this is not not a standard practice.

1) Almost every AAA title requires an update as soon as it is installed, even though it was purchased on release day.

2) Games in my Steam library get updates far more frequently than once a year. I had five different games updated just this past week (and I not counting early access games).

Once a year is not the norm for most studios.

That was the old way of doing things. These days, with agile development, an update every month is the norm for a lot of folks.

Indeed, they're following an Agile / DevOps approach... ;):thumbup:

I can't imagine 3rd party developers being prepared to only release a module once a year, they would struggle for cashflow and any fixes for bugs introduced would have to wait till the following year. As Chiclidfan says, don't update your own machine and let the rest of us enjoy the hype on a more regular basis

It might seem necessary for the OP to switch to a yearly model now because it's kind of a mess with 1.5, 2.1, beta, non beta... And I have to agree on that. But once 1.5 and 2.1 will have merged at the end of the year, things will get back to normal and will look tidy again.

It might seem necessary for the OP to switch to a yearly model now because it's kind of a mess with 1.5, 2.1, beta, non beta... And I have to agree on that. But once 1.5 and 2.1 will have merged at the end of the year, things will get back to normal and will look tidy again.

At the end of the year we are likely to only have an Open Alpha/Beta version of v2.5. It will still not be a full release version and the OP already stated that it would be sensible not to initiate his idea until after v2.5 was released.

This system would probably be most efficient after the 2.5 merge.

I partially agree with Woogey for the naming idea, the year instead of the version number maybe an idea, but not for the proposed release roadmap.

First of all, what sometimes is called stable release is still not a final version, but simply have less bugs than Alpha/beta: the DCS platform itself is a WIP, since ED it's expanding towards new horizons and most of the released modules are not out of beta stage.

Moreover, introducing a new module actually needs a new release of the Platform: people scared of using Alpha/beta will need to wait the new year to get new modules.

In final, I think that to reach a final-stable Platform in which you can enjoy modules, ED needs the help of users that play Alpha/beta to squash bugs (and receive complaints too?:lol:): more we are, faster we can reach a stable release.

So I'm more in line to the opinions of Cichlidfan / Cibit and I say: let ED push-out weekly alpha/beta/stable release

In final, I think that to reach a final-stable Platform in which you can enjoy modules, ED needs the help of users that play Alpha/beta to squash bugs (and receive complaints too?:lol:)

oft-repeated fallacy. the only thing you get is more feature creep suggestions because every audience member has their own fantasies they want to see realized.

it is the root of the reason why every software product is in perpetual early access nowadays, because there is no end or beginning. every product is a living, ongoing project, a service that grows with the audience.

-1 ;)

I don't agree with ED opting for a rigid approach like this, but some principles of schedule and continuity can be adopted once 2.5 is live and major bugs squashed.

What I mean is that we love getting improvements, and this shouldn't stop because of an arbitrary timeframe. However, the health of the DCS community relies heavily on external mission builders, and even modders to a significant degree. Right now, incremental updates in DCS, while welcome, tend to break earlier missions to the point that are most prolific mission designers are playing it safe with lua code so that they won't have to redo the mission in a short timeframe. Additionally, some of the best missions over the past few years break if you save them with the latest version of DCS (what was once a time-honored practice of ensuring compatibilty). As a modder, I have put all of my mods on hold because I don't have the time to test compatibility with every new build.

Once 2.5 is stable, what I recommend for ED is in line with the Agile process: Have a plan for incremental updates, post those plans, and post what datafiles/systems will be modified. For example, if I know that some nations are being added to the ME in a month, I can plan to update and test my Nations mod with respect to the new lua files. Likewise, if lighting is to change in 2 months, I know that I may need to update specular textures around that timeframe. Similarly, if features are added/modified in the ME, advance notice gives mission builders an idea of what to expect.

A solution like this allows innovation to thrive while encouraging and supporting the community in making DCS better than the sum of its parts.

You're confusing ED with EA..

this would be hard to integrate, as new technologies are developed and integrated as needed by new modules.

Even after 2.5 is released, it doesnt mean DCS World will go on what we call "Feature Freeze/Code Freeze".

DCS World will continue to evolve.