Too many updates!

Started by mobius, October 09, 2016, 04:49:08 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

mobius

Updates are great, bugs should be fixed and quickly, I'm not arguing against that, but this is getting to be a real problem/nuisance.

Would it be possible to limit updates to anything NL related, to like once a week, maybe even longer?

Updating frequently is good to get rid of problems but as it is; it's getting way too confusing trying to keep up with all the updates. It seems like I get the newest version and a day later already it's outdated so reported a bug gets problematic. There are now a ridiculous number of versions out and updating so frequently is also sort of a pain.

This is getting to be such a hassle that most of my time spent playing Lemmings is just updating/figuring out if certain things work correctly/what doesn't work correctly and moving files around.

Also I guess I should point out that I've had "update check" and online options on for a while now (for several versions) and it hasn't been telling me to get a new version or updating by itself. I've had to manually update every time. Maybe this is a by-product of a change that was made in response to Nepter's post. If it was I guess I change my stance; if updates are going to occur like this and continue to be this frequent, It would be much easier for the program to do it itself.

And, I think, starting now I will try to refrain from pointing out minor bugs like the volume slider, which I already posted about just before making this post. Things like this are minor and shouldn't really be focused on. They should be fixed, but when it's convenient. I feel like I'm wasting my and your time with this. And it just makes things more confusing. This is just too much a waste of my time.
everything by me: https://www.lemmingsforums.net/index.php?topic=5982.msg96035#msg96035

"Not knowing how near the truth is, we seek it far away."
-Hakuin Ekaku

"I have seen a heap of trouble in my life, and most of it has never come to pass" - Mark Twain


namida

Generally, an update will only be released for a few small things if either (a) the update fixes a critical bug (such as the incorrect fall distance in V1.48 that lead to the V1.48-B update), or (b) the changes aren't critical, and using the previous version remains practical.

As a general rule, for -B, -C etc updates, unless the update fixes such a major bug (which will usually be noted with the update release post), it isn't critical to update it. For major updates (eg. V1.47 to V1.48), the update is more important.

Since the updates often either fix such bugs (whether they're significant ones like that, or more minor yet nonetheless annoying ones), I prefer to get stable versions out when possible so that those who want the fixed behaviour (without having to rely on experimentals) can get it.

The update notification in the player should inform you that an update is available, but leave it up to you to download it. I can look into some kind of fully-automated update if this is preferred.

In general, if people have ideas on how to improve the release schedules etc, feel free to post them.

QuoteAnd, I think, starting now I will try to refrain from pointing out minor bugs like the volume slider, which I already posted about just before making this post. Things like this are minor and shouldn't really be focused on. They should be fixed, but when it's convenient. I feel like I'm wasting my and your time with this. And it just makes things more confusing. This is just too much a waste of my time.

It's much better to report them. If it turns out to be a duplicate, or unfixable, or too unimportant, so be it. However, if it is an important and/or easily-fixed bug - which the majority of reports are - then if you don't report it, it remains there, unknown, until someone else encounters and reports it. The worst thing that can come of a report / suggestion is that nothing changes; more likely, a bug will get fixed, or a suggestion will at least be given consideration.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

namida

One thought I had on how this could be improved is to better distinguish types of updates:
- "Critical" updates would be the most important, and a case where everyone is encouraged to update ASAP. This would usually imply significant backwards incompatibility, either due to format changes or physics changes.
- "Major" updates would be quite important, an example may be if a bug that causes NeoLemmix to crash or desync is fixed; or perhaps when a change in physics occurs that has very limited effect (an example would be the splatpad physics change). But, it would also imply that content remains 100% compatible.
- "Feature" updates would not be important, but add nice new features. For example, UI improvements, fixing of the windowing system, etc would fall under this.
- "Fix" updates would be primarily bugfixes, generally to fairly unimportant bugs that don't tend to interfere with gameplay but may simply be annoying.

An update that has elements of more than one of these would then take the highest status. For example, if an update fixes a crash and also adds a new feature, it'd be considered "Major".

So, if you see an update labelled "Critical" or even "Major", you would know that it's important to update as soon as you can. Whereas one labelled "Feature" or "Fix" is probably not urgent, and you can wait until a more convenient time or even just hold off until the next critical / major update.

These are probably not the best terms, but what do you think of this general concept? This would allow maintaining the current approach to a decent extent, but establish more consistency - as a general guideline (although current updates are not 100% consistent on this), a "critical" or "major" update would be somewhat equivalent to eg the difference between, say, V1.43 and V1.47; a "feature" update would be more like the difference between V1.47 and V1.48 or between V1.47 and V1.47-B, V1.47-C etc; while a "fix" update would be more like a new experimental version.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

Simon

#3
Merge major with feature, and you get semantic versioning.

It's for software with APIs, but physics are similar, because levels depend on physics.

When you fix a horrible crash, that's only a patch in semantic versioning. If that doesn't taste well, hunt around the web for downsides and alternatives to semantic versioning.

-- Simon

namida

I feel that, for the reasons that this topic came up in the first place, distinguishing between "major" and "feature" is important here. If there's compatibility issues (even if they don't quite go to the extent of fully rendering content unusable), like a "major" update would imply, updating is more important than if, eg, I've added support for a "skip to next shrugger" hotkey.

(Note to self: That might actually be a very useful hotkey to add.)
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

Simon

When the feature doesn't touch compat in any direction, then it's semver-patch, not semver-minor,

In reply #3, I have generalized features as equivalent to your major and semver-minor. I realize that's not what semver does. Semver looks only at compatibility, not at how big a feature you add.

-- Simon

namida

QuoteWhen the feature doesn't touch compat in any direction, then it's semver-patch, not semver-minor,

Fair enough, but I'd like to be able to distinguish between updates that just fix some bug, vs those that add a new feature (but one that doesn't impact compatibility).

I was thinking of a system like the following:

[file format version].[physics / core features version].[features version].[fix version]

File format version would be increased only in cases where the new files aren't compatible with older versions and vice versa. V1.48 (due to different NXP structure / lack of VGASPEC support) would be a case of this.

Physics / core features version would be increased where either (a) physics have changed, thus potentially causing levels to become unsolvable; or (b) new stuff has been added to the formats but older files remain usable; but the newer files might not work on older versions. An example here would be V1.47; older files remain compatible, but compatibility issues can occur (different physics). Likewise, the new files might not be compatible with older versions (due to the addition of object rotation).

Features version would be increased where a not-critical-to-gameplay feature has been added or modified. An example might be when postview screen jingles were implemented, or when shadows were improved.

In particular, the above three would not reset just because a higher-order number was changed. EG: If we were on version "40.30.20.X", and then a change was made to the formats, the next version would be "41.30.20.X", not "41.0.0.X". This would allow more user-friendly checking of compatibility - format number must match exactly, physics number is preferably equal but higher should be fine too. (Perhaps the features number could reset each time, I'm not sure here. I think I'd prefer not to still; then I could clearly state "This feature was introduced in Feature version 10" for example.)

The last one would be for hotfixes. This one would reset each time another number is increased, it's essentially a subversion of the main X.Y.Z version rather than a seperate part of the versioning.


One advantage to this system is that, for a large part, the existing convention of using a decimal number, followed by a letter and then occasionally another number could be kept. This would work better if the Features number was reset between versions though.

But I'm not against completely changing how versions are indicated, as long as there's a benefit from doing so.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)

Wafflem

I agree that updates really need to slow down except if they are to fix major bugs.

Another concern is the transition to the new graphic set format, translation tables and constructs, as well as moving some duplicate objects like updrafts to the default set. I would like a set date on when the new graphic set format will be used so that all of us can have time to transition to this new format.
YouTube: www.tinyurl.com/YTWafflem
Twitch: www.twitch.tv/Wafflem467

Have level designer's block right now? Have some of my incomplete levels for LOTS of ideas!

namida

Hopefully, this new version system I've introduced should help allow for the continuation of rapid updating, while making it more clear when updating is or isn't nessecary so those who don't want to bother getting every update know when an update isn't essential.

As a quick guide:

WWW.XXX.YYY-Z

WWW: Format version. Player and content should match versions exactly. Update is generally critical.
XXX: Core version. Player version should be equal or higher than content version; equal is preferable. Update is generally important.
YYY: Feature version. Does not matter. Higher version simply means more neat user-side features.
Z: Hotfix version. This is for updates that just fix bugs, rather than introducing features, changing formats, etc.



In regards to when full new formats will be used, I can't give a date yet. But I do plan to make switching as easy as possible, probably in the form of a dedicated upgrading tool.
My projects
2D Lemmings: NeoLemmix (engine) | Lemmings Plus Series (level packs) | Doomsday Lemmings (level pack)
3D Lemmings: Loap (engine) | L3DEdit (level / graphics editor) | L3DUtils (replay / etc utility) | Lemmings Plus 3D (level pack)
Non-Lemmings: Commander Keen: Galaxy Reimagined (a Commander Keen fangame)