Implement "version" field

[ssbucarlos]

In the bl_info, the app has always had (0,9,0). It would be nice to properly fill out this field. Im not sure what the best way for handling this would be, maybe (YYYY, MM, DD)?

The tuple can be expanded to have another int, maybe that one can be used to distinguish multiple commits on a day, or maybe the commit number?

[ScanMountGoat]

I would strongly suggest semantic versioning instead of inventing a new versioning scheme. The version after 0.9.0 would be 0.10.0. If you want to do build numbering, you could do something like 0.9.1 or 0.9.0.1. Whether or not you want to do a 1.0 release is largely up to preference since this isn't a library that people will use.

[ssbucarlos]

hmm since this isn't a library, for semantic versioning would something like X.Y.Z where X is incremented on major breaking changes between blender versions, Y on any new feature added or enhanced and Z on any bug fix work?

[ScanMountGoat]

That could work. Your date format technically works since the version will only ever increase. The problem is that people won't be able to tell if it's "safe to update". I would suggest using major versions for compatibility changes with existing scenes or blender versions. i.e. scenes from 0.10.0 may not work with 0.9.0. How many numbers you use is up to you. Some projects prefer 0.10 to 10.0.0. A major revision to 1.0 is 2.0. This distinction isn't super important since this isn't a package that people import in code though.

For Ssbh Editor, I use essentially what you described since the binary files never really "break" between versions. We can always document what Blender version is compatible on the release notes or in a table on the readme.

[ssbucarlos]

ok ty for the info, in that case ill change the numbering so that the 4.0 version releases as "1.0.0" and the final 3.6 one will be "0.10.0", just to know for sure someones on that final version instead of one of the many possibly outdated "0.9.0" versions