A Basic Remider During Update Periods

[TranceaddicT]

Folks, if you are using mods and KSP updates to a new version, you can be GUARANTEED some mods are going to break.

Many modders and those curating mods are aware of the change and will be all over the necessary changes to your favorite mods.

Please, PLEASE, give them some time before you start clamoring with your cries of "It doesn't work with KSP <insert version here."

About the ONLY time, you should comment on a mods functionality during this period is IF IT IS FUNCTIONING PROPERLY.

These folks work hard for US to enjoy an enhanced experience; let's cut them some slack.

[TranceaddicT]

Bumping this for Kerbal Space Program 1.6.0 'To Vee or Not To Vee'

[Snark]

Moving to Add-on Discussions, since this is not a mod release.

[theJesuit]

I like the grey box at the top that reminds people to not bother mods on the discussion pages.  I assume that it is temporary.  Is it not possible to have that added in the modding forums? And mods to add it to particular mod threads if people start getting angsty?

[Murdabenne]

Best solution: Wait at least 90 days before you upgrade unless there is a vital bug fix, or else play bone stock for a while. Mod authors have lives.

[RealKerbal3x]

Just now, Murdabenne said:

Best solution: Wait at least 90 days before you upgrade unless there is a vital bug fix, or else play bone stock for a while. Mod authors have lives.

BTW, SQUAD is now releasing quarterly updates, so if you waited 90 days (~3 months) after say, 1.7 then the game would be on 1.8 by the time you updated to 1.7.

[Murdabenne]

58 minutes ago, RealKerbal3x said:

BTW, SQUAD is now releasing quarterly updates, so if you waited 90 days (~3 months) after say, 1.7 then the game would be on 1.8 by the time you updated to 1.7.

Intended behavior. It means the version will be completely stable.  And to be honest, unless its a significant bug fix, these version bumps are not really bringing much anything new to those of us who run mods.   They should really be treated like maintenance releases on a case by case basis, since they are scheduled by date and not by function or content

Usually its [Major].[Minor].[Maint/Rev].buildnumber

Changing the minor every 90 days can be a bit misleading.  If you see something go from 1.5 to 1.6 you expect some sort of significant change, although there might not be any in terms of actual game functionality for a large portion of players (common KER usage for years). Squad wasn't originally a development company, so I guess they kind of wing it - for example, going from one unity version to another with a loss of backward compatibility should have merited an increment in the major version from 1.x to 2.x. Or do it like Blizzard does with WoW, increment a major with each expansion, and the minor moves up with large updates to content, and the patch level is for bug fixes.

The way I was taught is that Major only when there is a change to central functioning or multiple APIs are changed with no backward compatibility. Minor only when there is a significant addition of core functionality with backward compatibility, or a single API with limited impact is changed with no backward compatibility. Maint is for scheduled releases from a process standpoint (quarterly releases, finished a bugfix sprint, small addition to content, etc), as well as urgent releases like bug fixes or minor non-vital content additions (recolored or new model for existing content). 

Or it could be something simple: Like marketing is driving version numbers, something that's not all that uncommon (Windows 10 not 9, etc).  And I have to admit seeing 1.6 instead of 1.5.2 and 1.7 instead of 1.5.3 does look a bit more impressive from a marketing standpoint (and I want them to stay in business, I love this game)

Edited December 22, 2018 by Murdabenne
hit enter too soon