Starmade design versioning

[Jeryia]

Howdy!
I've been looking at my catalog of the various stuff I've built in starmade and been finding my methods of organizing them in terms of version related to starmade's changes has been pretty aweful. So I've been putting thought into making a new versioning system. As systems design doesn't change with every update, it seems logical to have a seperate versioning scheme from the base starmade version.

Current thoughts for where we are now is 2.2.0:
* 1.x being pre power update
* 2.x being power power update
* 2.0 being initial release of power update
* 2.1 being the initial balance changes to it /removing the power stream thing
* 2.2 being quickfire mods

Advantages of such a versioning scheme:
1. Easily quantifies the current version in relation to how starmade has changed things for ship design.
2. Easier to tell (in comparison to using the real version of starmade) if a ship is up to date (or at least how close)

Disadvantages:
1. As it doesn't match starmade's version, it requires more work to determine what version to call something. Generally internally it will only get updated if the builder realizes things have changed, which could harm collaboration between players.

Thoughts? How do you guys manage this?

 

[JinM]

I use an adapted scheme of semantic versioning, this means a three number string. (aa.bb.cc)

1. If I use a new complete new weapon system (from power 1 to 2) I would just increase the first number (aa).
2. If I just adapt my system from power pre-qf to quickfire I would just increase the second number (bb).
3. If I just change a few weapon system blocks and it's not because of changed game mechanics (from 79 to 81 cannon modules) I would increase the third number (cc).

My own Versioning conventions in CC uploads:

(major.minor.internal)= aa.bb.cc; for example SLV Denuvo 1.02.00

aa=major change (e.g. new weapons setup, role changed);
bb=minor change (this change is still noticeable by a user and he should read the change as it has impact on how he uses the vessel or on how he perceives it as it changed visually);
cc=internal change (everything is nearly the same for the user and he doesn't really need to take notice, still it's changed in some way; for example changing rail dockers would not be an internal change but a minor one, as the user needs to know this as he has to adapt his rails - on the other hand fixing some interiour blocks that got rotated wrong, or fixing spelling mistakes in displays is a typical internal update)

example:

https://starmadedock.net/content/starter-exploration-vessel-slv-denuvo-completed-regular-version.8025/updates

 

[Jeryia]

ok, thanks!