Recent Negativity Regarding OpenMW

General discussion regarding the OpenMW project.
For technical support, please use the Support subforum.
Chris
Posts: 1625
Joined: 04 Sep 2011, 08:33

Re: Recent Negativity Regarding OpenMW

Post by Chris »

While I don't have an issue inherently with symantic versioning, I do have to seriously question it's viability post-1.0. Having 1.0 be a marker for feature parity is great, it's intuitive, and it lets people understand what the project's goals are. But after 1.0, especially for an open source volunteer-based project, versions after that start to become... muddy. Currently the idea is to have 2.0 be multiplayer. But why that specifically? What happens if proper multiplayer support takes longer than anticipated, but plenty of other great big features make their way in during that time (redone renderer, MGE parity, etc)? It'd be kind of silly to have version 1.47 feature full MGE parity or for version 1.63 feature fully dehardcoded Morrowind-specific mechanics, but not roll-over to 2.0 until multiplayer specifically is achieved and stable. Different people will care about different things, so beyond 1.0 being feature parity with vanilla, whatever goal posts are planted for 2.0, 3.0, 4.0, etc, will be arbitrary and put people off (some people won't care about multiplayer, and see more value in fully dehardcoded mechanics, for instance), as it makes it seem like the project is focused exclusively on that goalpost to reach the next version, even though their desired big features may still come in during that time. Not to mention, when you get to versions like v1.74, v1.126, v1.154, I have to wonder what's the point of the 1. part; v74, v126, v154 would tell me the same information, with the difference being it won't roll back to 0 after some arbitrarily defined feature is completed.

To me, it seems more fitting to either make each version be its release number (e.g. the next release after 1.0 is 2.0, and a bug fix release would be 2.1, and the following release is 3.0, etc). This could get to large numbers, but it's not that abnormal (nVidia drivers are at version 396.45, for example). The alternative would be to use the dates-as-version method, like how Ubuntu has release 2018.04, which was the release for April 2018 (and 2018.04.1 for the first bug fix release, etc). Specific features can then be given as titles for the release, so one version would be the big Dehardcoded Release, another would be the big Multiplayer Release (or something, I suck at naming, I'm sure someone can come up with something catchier). That makes more sense to me given that we can't know ahead of time when specific features will be completed due to being on a volunteer basis, and it doesn't put people off who prefer Big Feature X, but the next target version is already slated to be for Big Feature Y.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Recent Negativity Regarding OpenMW

Post by AnyOldName3 »

I don't think 2.0 has ever been tied directly to multiplayer - it's just been used as an example of a totes-amazeballs feature that could trigger a major version increment. As I understand it, 2.0 and 3.0 etc. will happen once either there's a major breaking change which makes content which did work completely not work (e.g. dropping NewScript in favour of NewScript 2) or there's a major jaw-dropping feature which completely changes the future of the engine (so a modernised alternative renderer would be a candidate).

Having the leading 1 is useful because there will be people who muddle up 43 and 0.43.

The specification for semantic versioning caught me a little off guard. Several projects I've seen use the phrase 'semantic versioning' use it to mean what we've been saying it is (i.e. major.feature.patch) and don't have a public API. I guess that what it means to a lot of people is just simply not what it means to the people who invented it.
Chris
Posts: 1625
Joined: 04 Sep 2011, 08:33

Re: Recent Negativity Regarding OpenMW

Post by Chris »

AnyOldName3 wrote: 29 Jul 2018, 00:56 As I understand it, 2.0 and 3.0 etc. will happen once either there's a major breaking change which makes content which did work completely not work (e.g. dropping NewScript in favour of NewScript 2) or there's a major jaw-dropping feature which completely changes the future of the engine (so a modernised alternative renderer would be a candidate).
The former will never happen, AFAIK. If something works in 1.0, it will work in 2.0, 3.0, etc. It's not going to break backwards compatibility for publicized behavior. If as a hypothetical it ever does, it would likely only be for a severe mistake that never really worked right, or was ill-thought and is causing bigger problems for other things. In such a case, the break would be as small as possible. So yeah, something broke between 1.56 and 2.0 making some things might not work anymore, but most things will still work so most users wouldn't see a problem using 1.x content with 2.x or 3.x.

Conversely, the imperfection of developers as human beings mean bugs happen and may go unnoticed. Updating from 1.34 to 1.35 may see something break that's not caught until much later. Consequently, users will see "potentially breaking update 2.0" not actually break anything they use, while "not breaking update 1.35" might break something they use. Or worse, a user sees "potentially breaking update 2.0" and finds something they use doesn't work anymore, so they assume it was some casualty of the breaking change, but the failure they experience is actually a bug, which they don't report because of a false assumption. So what was gained?

The latter reason for a major version change is a lot trickier to deal with than it may seem. Updates tend to be incremental, for example it won't be that Multiplayer gets dropped into the codebase and Zini Said It Was Good. Instead, it'll be implemented in a (barely) functioning state that most players would not be happy with. Usable in a basic sense, but far from Prime Time. Over time it gets improved with each release. So at what point would the next major version apply? Most likely it will be after the last few touches are done that checks off the last of a predefined list, which will ironically mean the 2.0 multiplayer release might not have seen much significant multiplayer-related work from 1.76 or whatever.

I struggle with this for OpenAL Soft... I've been stuck on 1.something for years, waiting for the one big thing to push it to 2.0. Despite all the improvements made since 1.0 (and there's been plenty significant steps), no one release was enough to push it to 2.0 since it was relatively minor changes from the last. And since I'm never going to break backwards compatibility, the '1.' isn't telling anyone anything. All the version number represents is that it's newer than lesser version numbers and older than the greater version numbers, and there are cleaner ways to do that. If there's any new feature that I'm particularly proud of that got into the release, I can add it as a title to the PR statement.
Having the leading 1 is useful because there will be people who muddle up 43 and 0.43.
Then call it 43.0 to differentiate it from 0.43. Or use the release year.month scheme. As it is, people already muddle up versions like 0.40 (some calling it 0.4), or 0.42 (some calling it 0.4.2). Heck, the Unreal Engine recently updated to version 4.20, and I was seeing some tech-minded people calling it version 4.2.
User avatar
Atahualpa
Posts: 1176
Joined: 09 Feb 2016, 20:03

Re: Recent Negativity Regarding OpenMW

Post by Atahualpa »

Oh man, someone better move this to a new thread. Anyway:

Chris wrote: 29 Jul 2018, 02:24 [...] If something works in 1.0, it will work in 2.0, 3.0, etc. It's not going to break backwards compatibility for publicized behavior. If as a hypothetical it ever does, it would likely only be for a severe mistake that never really worked right, or was ill-thought and is causing bigger problems for other things. In such a case, the break would be as small as possible. So yeah, something broke between 1.56 and 2.0 making some things might not work anymore, but most things will still work so most users wouldn't see a problem using 1.x content with 2.x or 3.x.
That's why we shouldn't use the term "semantic versioning" when describing our versioning scheme - "major.minor.patch", as mentioned above, is sufficient.
Chris wrote: 29 Jul 2018, 02:24 The latter reason for a major version change is a lot trickier to deal with than it may seem. Updates tend to be incremental, for example it won't be that Multiplayer gets dropped into the codebase and Zini Said It Was Good. Instead, it'll be implemented in a (barely) functioning state that most players would not be happy with. Usable in a basic sense, but far from Prime Time. Over time it gets improved with each release. So at what point would the next major version apply? Most likely it will be after the last few touches are done that checks off the last of a predefined list, which will ironically mean the 2.0 multiplayer release might not have seen much significant multiplayer-related work from 1.76 or whatever.
But that's the whole point for me: We develop a new, great feature Xyz (or a bunch of them), thoroughly test it, and fix the most apparent issues - until our engine is stable regarding that feature. Then, and only then, we will increase our major version counter to indicate that players can safely use OpenMW with feature Xyz. Remember that the majority of players is not as involved with the project as we are (let alone with the actual development). They will most likely wait until somebody says "Feature Xyz is finally ready!", and why would we leave that task to reddit or discord users? The version number will do.
Chris wrote: 29 Jul 2018, 02:24 Then call it 43.0 to differentiate it from 0.43. Or use the release year.month scheme. As it is, people already muddle up versions like 0.40 (some calling it 0.4), or 0.42 (some calling it 0.4.2). Heck, the Unreal Engine recently updated to version 4.20, and I was seeing some tech-minded people calling it version 4.2.
On a side note: I wonder, has this something to do with "." being the decimal separator in English, leading people to confuse version numbers with actual numbers? In German, we use a "," - and I've never met a person who messed up "."-separated version numbers.
davidcernat
Posts: 256
Joined: 19 Jul 2016, 01:02

Re: Recent Negativity Regarding OpenMW

Post by davidcernat »

Chris wrote: 29 Jul 2018, 02:24 The latter reason for a major version change is a lot trickier to deal with than it may seem. Updates tend to be incremental, for example it won't be that Multiplayer gets dropped into the codebase and Zini Said It Was Good. Instead, it'll be implemented in a (barely) functioning state that most players would not be happy with.
Chris, we already have mostly functional multiplayer that people tend to generally be impressed with. I don't see us working towards a significant downgrade in that area.
Chris
Posts: 1625
Joined: 04 Sep 2011, 08:33

Re: Recent Negativity Regarding OpenMW

Post by Chris »

davidcernat wrote: 29 Jul 2018, 19:51 Chris, we already have mostly functional multiplayer that people tend to generally be impressed with. I don't see us working towards a significant downgrade in that area.
That's in a separate codebase that's focused on providing a multiplayer experience, isn't it? OpenMW is going to remain single-player focused and just get an option for multiplayer. I don't think OpenMW is going to become TES3MP in all but name, it'll just take relevant changes to get similar functionality. Plus, rather than merging it wholesale, the opportunity could be used to add the changes in piecemeal, rewriting any portions that may be due for a rewrite, or which could do with some cleaning (refactors within a pre-established codebase are difficult to do because of the way things rely on each other, while it's less difficult to rewrite parts as they get slowly integrated into a separate codebase where things don't yet rely on it).
davidcernat
Posts: 256
Joined: 19 Jul 2016, 01:02

Re: Recent Negativity Regarding OpenMW

Post by davidcernat »

Chris wrote: 29 Jul 2018, 20:53 That's in a separate codebase that's focused on providing a multiplayer experience, isn't it? OpenMW is going to remain single-player focused and just get an option for multiplayer. I don't think OpenMW is going to become TES3MP in all but name, it'll just take relevant changes to get similar functionality. Plus, rather than merging it wholesale, the opportunity could be used to add the changes in piecemeal, rewriting any portions that may be due for a rewrite, or which could do with some cleaning (refactors within a pre-established codebase are difficult to do because of the way things rely on each other, while it's less difficult to rewrite parts as they get slowly integrated into a separate codebase where things don't yet rely on it).
TES3MP has been designed in such a way that adding isMultiplayer checks throughout the codebase can completely disable the multiplayer functionality and provide an experience identical to OpenMW. Essentially, it's been working towards "OpenMW with an option for multiplayer" from the start instead of diverging towards multiplayer-oriented restructuring. That's actually why merge conflicts are so easy to resolve in it when taking in the latest commits from OpenMW.

Taking the multiplayer code in piecemeal does sound very reasonable, but TES3MP is never going to diverge from the OpenMW codebase more than it needs to, i.e. if we don't have a situation where OpenMW gradually becomes TES3MP in all but name, then we'll just have one where TES3MP gradually becomes OpenMW in all but name.
User avatar
Br0ken
Posts: 243
Joined: 02 Apr 2012, 05:54
Location: Siberia

Re: Recent Negativity Regarding OpenMW

Post by Br0ken »

Looked today at Morrowind Modding Community Discord channel. So much toxic opinions about OpenMW... :( Why?
Equinox
Posts: 19
Joined: 31 Jul 2018, 20:13

Re: Recent Negativity Regarding OpenMW

Post by Equinox »

Br0ken wrote: 31 Jul 2018, 17:01 Looked today at Morrowind Modding Community Discord channel. So much toxic opinions about OpenMW... :( Why?
I think it is more about fear.
The redundancy of MWSE mods is directly proportional to the advancement of OpenMW.
User avatar
Br0ken
Posts: 243
Joined: 02 Apr 2012, 05:54
Location: Siberia

Re: Recent Negativity Regarding OpenMW

Post by Br0ken »

Equinox wrote: 31 Jul 2018, 22:29 The redundancy of MWSE mods is directly proportional to the advancement of OpenMW.
As I understand, Lua support in OpenMW can give us some compability with MWSE2 scripts. Am I wrong?
Locked