How do you version your mod?

[SiliconPyro]

I'm not asking about theory or best practices, I want to hear from modders about how they personally version their own mods. I'm about to make my humble part available for download and I'd rather be slightly more formal than "I made a thing".

[magico13]

For Kerbal Construction Time, since it is still in pre-release, I start with 0. The next number is for major releases (currently 7), the next for bigger patches that may include new content or multiple changes (2), and the last number is for minor hotfixes (3). Bringing it up to 0.7.2.3. StageRecovery follows a similar pattern. Many people use the last number for the build number (github commit, or the actual number of times the plugin has been built). I obviously do plugins, not parts, so that numbering system may not translate directly to you.

[WololoW]

I understand you don't want theory, but I know squads method and figured I would share that.

X.YY.ZZ.AAA

X- Reserved for scope completion build. (once KSP reaches scope completion, it will be 1.YY.ZZ.AAA)

YY- Current pre-scope-completion released build. (Currently X.24.ZZ.AAA)

ZZ- Reserved for hot fixes to released build from previous part. (Currently X.YY.2.AAA)

AAA- Used every time a new build is created(but not necessarily pushed to public) (Currently X.YY.ZZ.459[?])

Hope that helps!

[SiliconPyro]

Thanks, guys. WololoW, that is helpful.

[sarbian]

Thanks, guys. WololoW, that is helpful.

You can't use such complex scheme without an automatic build system. Keep it simple : X.Y change when you add major feature and for bug fix

Or use the KSP version it was built for and add an other number to it (x. Y. Z)

-

[SiliconPyro]

You can't use such complex scheme without an automatic build system. Keep it simple : X.Y change when you add major feature and for bug fix

Or use the KSP version it was built for and add an other number to it (x. Y. Z)

-

Yeah, I definitely want to keep it simple. I'm thinking maybe [release].[content addition].[bugfix/polish].

[WololoW]

You can't use such complex scheme without an automatic build system. Keep it simple : X.Y change when you add major feature and for bug fix

Or use the KSP version it was built for and add an other number to it (x. Y. Z)

-

I dont understand why one would need automation in order to do that...

I can easily use the method I described without having a program do it for me... Hence my being able to write it out and not being a computer/program myself.

Edit* That being said, I feel that the AAA section I described is useless unless you have internal testing.

[SiliconPyro]

I dont understand why one would need automation in order to do that...

I can easily use the method I described without having a program do it for me... Hence my being able to write it out and not being a computer/program myself.

Edit* That being said, I feel that the AAA section I described is useless unless you have internal testing.

Yeah, the AAA section is possible, just unnecessary unless you have multiple people on your team and need to coordinate testing.

[regex]

I used a simple system based on whether the release was major or a bugfix. vx.y.z, where x and y are just the major version as a decimal (it just counts up from v0.1) and z is the bugfix version which is ommited from any major release and tacked on if the major release needed the bugfix (v0.7 needs a bugfix so the next release is v0.7.1. When the next major release hits it's v0.8).

Anyway, everyone has their own scheme and reason for using that scheme. The important thing is that your users know what version to install.

[NathanKell]

Basically same as regex: major.minor.bugfix.