You and others can reference specific versions of the scripts, without knowing anything about Git. "How do I know it's version 1337? Well, it says ; Version 1337 close to the top of the file"
Methods:
a.b.c: 1.2.3: Bump to version 1.2.4 for a bugfix, 1.3.0 for a small feature, 2.0.0 for a major rewrite, incompatibilities, big feature, to feel nice and accomplished
YEAR.v: 2021.58: 1st number is current year, 2nd number is what version came out that year. So after 2021.568, which came out on 31dec2021, it's time for 2022.1. Or 2023.1, if no update was made in 2022.
I suggest going for the 2nd one if you think you'll spend too much time agonising over whether this update is big enough to call it an a.b.c-release, or instead is an a.b.c-release
A downside of the 2nd one is that going back can be hard, if this gets into some system that checks whether you're using TaranScript 2021.568 or greater. It's not going to accept 5.7.31, even though it came out long after 2021.568.
Could be mitigated by switching to YEAR.a.b.c: 2021.5.7.31 -> 2022.5.7.32
a.b.c communicates a little more to people seeing the numbers, YEAR.v requires no thinking when making a new version
If you're unsure, start with a.b.c. Easier to explain if you switch from that one as well, to hilaaarious people who would "LOL why did regress from version 2000-something to version 4? lmao"
I think it would be a good idea to version the different scripts, such as QMK_F24_macro_keyboard.ahk, separately: "Oh, main-script 2021.5 is incompatible with QMK-F24 2021.8"
Yes, remembering to bump the version (as it's called) is another thing to remember, but even if you forget sometimes, this is better than no versioning at all, and can easily be corrected after the fact.
Scenario:
We're on 2021.5 now
You make a change, but forget to bump it to 2021.6
You make another change, notice that you didn't bump to 2021.6
You instead bump it to 2021.7
Increasing those numbers is free, and you don't owe 2021.6 anything
To be very clear: v is not the current month. Even though it's after the year of release. Hence the possibility of version 2021.568
You and others can reference specific versions of the scripts, without knowing anything about Git. "How do I know it's version 1337? Well, it says
; Version 1337close to the top of the file"Methods:
I suggest going for the 2nd one if you think you'll spend too much time agonising over whether this update is big enough to call it an a.b.c-release, or instead is an a.b.c-release
A downside of the 2nd one is that going back can be hard, if this gets into some system that checks whether you're using
TaranScript 2021.568 or greater. It's not going to accept 5.7.31, even though it came out long after 2021.568.Could be mitigated by switching to YEAR.a.b.c: 2021.5.7.31 -> 2022.5.7.32
a.b.c communicates a little more to people seeing the numbers, YEAR.v requires no thinking when making a new version
If you're unsure, start with a.b.c. Easier to explain if you switch from that one as well, to hilaaarious people who would "LOL why did regress from version 2000-something to version 4? lmao"
I think it would be a good idea to version the different scripts, such as QMK_F24_macro_keyboard.ahk, separately: "Oh, main-script 2021.5 is incompatible with QMK-F24 2021.8"
Yes, remembering to bump the version (as it's called) is another thing to remember, but even if you forget sometimes, this is better than no versioning at all, and can easily be corrected after the fact.
Scenario:
Increasing those numbers is free, and you don't owe 2021.6 anything
To be very clear:
vis not the current month. Even though it's after the year of release. Hence the possibility of version 2021.568