Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recommendation: Version the scripts #142

Open
Jonta opened this issue Jun 17, 2021 · 0 comments
Open

Recommendation: Version the scripts #142

Jonta opened this issue Jun 17, 2021 · 0 comments

Comments

@Jonta
Copy link

Jonta commented Jun 17, 2021

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:

  1. 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
  2. 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant