What else?

[lazduc]

What else that has been said by ED needs to be finished before the merge of 1.5/2.0 into finally 2.5. Errr hope I got the numbers correct...:D

 

Laz

[probad]

what good would this information do you or any of us?

 

-we're not the ones getting the work done

-it doesn't put anyone in control of unforeseen snags

-it creates an illusion of certainty that leads to perceptions of unfulfilled promises

[lazduc]

Ask a question here and get ............

 

ED has mentioned several issues that they are currently doing that need to be finished prior to the merge. I simply asked what they were.

 

I really don't know if any information would do You any good....

I am relieved that you are not doing any of the work......with your condescending remarks....

 

and your illusion of certainty, that information from ED leads to perceptions of unfulfilled promises is most absurd and completely misleading. As misleading as your perception of my simple question. Please, if you cannot contribute in a constructive and civil manner try keeping your unwarranted responses and put them where the sun doesn't shine.

[SkateZilla]

2.1 w/ NTTR and Normandy will be out this week according to news letter,

 

For 2.5, it's waiting mainly on the Caucasus Rebuild.

 

Once Caucasus Rebuild is done, 2.5 will likely one at a time take over branches, Alpha, Beta then release, 1.5 w/ old Caucasus will move to unsupported branches.

[lazduc]

Skate, Great, thanks for the info. Do you know if ED is going to continue with multiple builds after the merge? What I mean is ED going to have a build that is a wip with the intention of having the community help spot and report bugs? Like when a new module is introduced, instead of integrating into 2.5 stable with the chance of it causing problems, just have another build for testing, alpha testing if you will? Just curious, as I wonder with the communities help in support lead to a faster stable release?

[Winston 60]

what good would this information do you or any of us?

 

-we're not the ones getting the work done

-it doesn't put anyone in control of unforeseen snags

-it creates an illusion of certainty that leads to perceptions of unfulfilled promises

Hey Sport, why the snide remarks? The guy asked a simple question asking for information. In fact, most of the posts you make here are derogatory in nature. Do you ever contribute anything positive to this community?

 

Look at SkateZilla's post and see how you could possibly have done better. Maybe you can turn over a new leaf today and start replying with a little compassion to your fellow forum mates. We are not your enemies.

[MikeMikeJuliet]

Skate, Great, thanks for the info. Do you know if ED is going to continue with multiple builds after the merge? What I mean is ED going to have a build that is a wip with the intention of having the community help spot and report bugs? Like when a new module is introduced, instead of integrating into 2.5 stable with the chance of it causing problems, just have another build for testing, alpha testing if you will? Just curious, as I wonder with the communities help in support lead to a faster stable release?

 

I suspect ED will continue having a singular stable release and the occasional beta branch for the exact reason you described. That said, the stable release is the one intended for the majority of users.

 

Regards,

MikeMikeJuliet

[OnlyforDCS]

I suspect ED will continue having a singular stable release and the occasional beta branch for the exact reason you described. That said, the stable release is the one intended for the majority of users.

 

Regards,

MikeMikeJuliet

 

I hope that's the case. Supporting multiple branches for 2+ years was probably a logistical nightmare, and as a user it was a hassle and at one time even made me quit DCS. (To wait for the merge)

[QuiGon]

I can only agree with what SkateZilla and MikeMikeJuliet said: The merge is more than anythying waiting on the upgrade of the Caucasus map and after the merge there will probably be a stable release branch and a beta branch (with the alpha branch probably getting dumped).

[SkateZilla]

All 3 Branches will likely remain even after 2.5 Takes over Release.

 

Release = Less Frequent Updates, More Stable w/ Minimal Bugs and no Breaking problems

Open Beta = More Frequent Updates, testing before they goto release branch

Open Alpha = Advanced Updates of new Features (Ie, New Maps, New Modules, etc etc)

 

 

All 3 Branches will be based on the same Core Features, unlike now, where Release/Open Beta are Still using T3, older Lighting etc, while OpenAlpha Uses T4 and is getting PBR/Deferred w/ the next update.

Just OpenAlpha will introduce Alpha Versions of Items, Beta will test multiple fixes, and Release will be for the most part stable.

Edited May 23, 2017 by SkateZilla

[cichlidfan]

All 3 Branches will likely remain even after 2.5 Takes over Release.

 

Release = Less Updates, More Stable w/ Minimal Bugs and no Breaking problems

Open Beta = More Frequent Updates, testing before they goto release branch

Open Alpha = Advanced Updates of new Features (Ie, New Maps, New Modules, etc etc)

 

Keeping all three branches would be silly. The Open Alpha will serve no useful purpose except to continue creating the extra work required to maintain it.

[rrohde]

What became of the ATC update? There hasn't been a mention of it in what seems a really long time, but it's such an essential component of aviation to get that right.

[Mars Exulte]

The Merge is nigh!!!!

Giggity giggity =)

 

@Cichlidfan

I think you are misunderstanding.

Every development has multiple stages, Alpha, Beta, release. Currently we basically have two parallel games in 1.5 and 2.0, with varied stages in them and each built on a different code base.

 

After the merge, we'll only have one primary code base, but it will still have alpha, beta, and release versions. These do not require 'extra upkeep'. They are varied stages of development. They exist, period. Alpha is when they first start coding something new, beta when it's mostly working, and release after it is effectively finished.

 

The difference? We can delete all our 1.5 stuff and will only have the one install, unless someone chooses to participate in it. It will not require anything 'extra' from ED. These stages exist regardless.

[Johnny Dioxin]

I have an old 1.2 installer that I intend keeping in order to fly the many missions I didn't get a chance to that were broken by updates and never fixed.

 

I have hundreds of them - literally. So much hard work and exciting ops - I refuse to just ditch them, especially when the number of decent missions has fallen so drastically (and I don't believe that we will get a surge of any significance once 2.5 arrives).

 

Remember how many great mission contributions we used to have with FC? That's why I still have that installed on a 2nd PC, too.

[cichlidfan]

The difference? We can delete all our 1.5 stuff and will only have the one install, unless someone chooses to participate in it. It will not require anything 'extra' from ED. These stages exist regardless.

 

Distribution of 'patches' to any public release still requires extra work. I doubt ED creates patches for the tester's versions. They are likely to be downloaded as complete packages, like the backer's v2.1 package, which is far easier to maintain and distribute.

 

During my employment in the IT world, I supported a large group of software devs and we only ever sent out patches in an emergency. Normal, quarterly, updates were delivered as a complete re-installation of the product. This process eliminated many possible issues that can arise from have to write code whose sole purpose was to weave the changed parts of the code with the unchanged parts of the code.

Edited May 23, 2017 by cichlidfan

[OnlyforDCS]

What became of the ATC update? There hasn't been a mention of it in what seems a really long time, but it's such an essential component of aviation to get that right.

 

This improvement (like many others) has to wait for the merge. There was simply no sense in implementing it in one engine, and then doing it all over again (with all the testing that requires) in a completely different engine. This is why the merge is such a big deal. (Apart from the obvious graphical upgrades and multiple theater support)

[SkateZilla]

Keeping all three branches would be silly. The Open Alpha will serve no useful purpose except to continue creating the extra work required to maintain it.

 

Distribution of 'patches' to any public release still requires extra work. I doubt ED creates patches for the tester's versions. They are likely to be downloaded as complete packages, like the backer's v2.1 package, which is far easier to maintain and distribute.

 

During my employment in the IT world, I supported a large group of software devs and we only ever sent out patches in an emergency. Normal, quarterly, updates were delivered as a complete re-installation of the product. This process eliminated many possible issues that can arise from have to write code whose sole purpose was to weave the changed parts of the code with the unchanged parts of the code.

 

w/ 2.5 All 3 Branches will be Based on the Same Code String, So you're really only maintaining 1 Compiled Branch.

 

The Only Difference will be update frequency and items being available on OA First then OB then REL.

 

Open Alpha will get more updates earlier and new maps etc.

 

once those are tested, the update will roll into Open Beta, then Release.

 

Final Compiled Branches, will all be based on the same Code, Features, Engines, etc,

 

There isnt going to be 3 separate Code Strings for each Branch,

 

Even now, Rel/Ob/Oa is technically based on the same code, you just have different underlying engines due to 1.5 being T3 and 2.x being T4, etc etc. plus a bunch of other technical things I wont get into.

 

It makes complete sense for anyone that's done programming and software development.

 

 

 

Basically (And Generally, as there's usually more steps, but a rough map would be):

 

MASTER DEVELOPMENT CODE -> COMPILE TO OPEN ALPHA Version X.X.X.XXXX -> Users/Testers Report Bugs -> Bugs are Fixed in MASTER DEVELOPMENT CODE -> Compile NEW OPEN ALPHA Version -> Test, Repeat -> Fix More Bugs -> Compile New Open Alpha and Open Beta Version X.X.X.XXXX -> Beta Participants Find More Bugs -> Bugs are Fixed in MDC -> New Open Alpha / Beta Compiled -> Test bugs fixed, no new ones introduced -> Compile New OA, OB, and New Release Version from MDC.

 

The Issue of 1.5 and 2.0 right now is the Underlying UI and Engines are different, Developers develop for 1.5 and 2.0 Separately as they use different Binaries for the underlying engines.

Developers wont have to worry about this once 1.5 is phased out.

Edited May 23, 2017 by SkateZilla

[Schmidtfire]

Nope. I dosen't make any sense to me. ED needs to stop splitting the game up into fragments, all it will bring is frustration and confusion. I understand the need for beta/alphas, but they should not be public after the 2.5 merge. I think it's better to keep it simple and figure out a more efficient solution to patch DCS instead. Like a big patch followed by one or two small hotfixes as soon as the first bug reports start rolling in.

[cichlidfan]

It makes complete sense for anyone that's done programming and software development.

 

Not to anyone who has had to support the untested software once it is in the wild. Internal development and what you distribute to the world wide public are two vastly different things.

[SkateZilla]

Not to anyone who has had to support the untested software once it is in the wild. Internal development and what you distribute to the world wide public are two vastly different things.

 

True, But it's the End Users' decision to Opt In to the Open Beta / Open Alpha Programs.

 

Once 2.5 is on Release Branch, users that dont want multiple installs wont need them to access all the maps etc.

[cichlidfan]

True, But it's the End Users' decision to Opt In to the Open Beta / Open Alpha Programs.

 

Once 2.5 is on Release Branch, users that dont want multiple installs wont need them to access all the maps etc.

 

So what. Even if only 12 people 'opt-in' time and effort must still spent in supporting those users. Unless ED decides that it will not listen to, or provide support for, any issues that a user has with an Open Alpha problem, their distribution will still complicate the support task.

 

Just having to verify which version a user has issues with is an extra step that can be eliminated.

[Flagrum]

I think that providing patches/updates to three branches (technically more "versions" of the same code base) is not too dificult - ED has with the autoupdater a quite decent tool for that. But maintaining these three versions might add some additional effort internally for ED. By far not as much as maintaining different versions of even different code bases, but still. And to be honest: I don't really see the benefit for keeping a public Alpha version - neither for ED, nor for us customers. It will lead only to confusion again ... Besides, official terminology is now "early access", right? So I would be completely happy with one Stable Release and one Early Access version ...

[Winston 60]

.... Even if only 12 people 'opt-in' time and effort must still spent in supporting those users....

I think you're looking at this backwards. ED isn't supporting open alpha and open beta users, rather the open alpha and open beta users are supporting ED by providing pre-release input, suggestions and bug reports. It's either that or throw out release versions full of bugs and then we get frustrated and wonder why so many bugs exist and how they can call it a stable version.

[Zimmerdylan]

I think you're looking at this backwards. ED isn't supporting open alpha and open beta users, rather the open alpha and open beta users are supporting ED by providing pre-release input, suggestions and bug reports. It's either that or throw out release versions full of bugs and then we get frustrated and wonder why so many bugs exist and how they can call it a stable version.

 

 

Yes.....And it drives me crazy out of my mind the people either do not understand this or they seem to forget it altogether.

[MikeMikeJuliet]

All this considered, why would ED need any public alphas constantly after 2.5?

 

Before Nevada became a thing all we had was a stable and a beta branch. The alpha was made strictly because ED can't have multiple maps on 1.2/1.5 versions of the game. So, after 2.5 is out and all three current maps are in there, why would ED need to have an alpha for a new map? Why not throw it into the beta branch, since the new engine can handle multiple maps?

 

I mean this is exactly what happens with the upcoming alpha releasd of Normandy. It does not get it's own version, instead it is added to the 2.x branch. It is alpha only because 1.5 still exists.

 

With that argument, I do think ED will only release stable and beta builds for the public after 2.5 is out.

 

 

And all THAT said... why are we arguing over this? It is not our call to make. And different software houses and game developers do things differently. Just because someone worked on a program doesn't mean they know how every developer handles their projects.