Author Topic: Build counters?  (Read 8186 times)

0 Members and 1 Guest are viewing this topic.

Offline keybone

  • Forum Regular
  • Posts: 116
  • My name a Nursultan Tulyakbay.
    • View Profile
Re: Build counters?
« Reply #15 on: August 12, 2018, 01:18:54 am »
I believe version numbers should be something that evolves consciously and the owner of the software should be able to judge when to change it. Automating the process sounds irresponsible.

Let me explain a little bit, I don't wanna write too much so im gonna be real simple about it...
I forget to keep track of my progress with versioning all the time, I can never just work on a bunch of code and come up with a structured way to be like this is version 1.0, 1.01, 1.1, etc. I could always just ignore this, but... I desire to have some kind of a versioning system.

So the reason this works for me is:

When I make significant progress, I can just be like "Hey, this is a good one. What build is this?" Wouldn't really be talkin to myself but the point is I can just look at the build number and be like this is build 2838.... I can ask someone who tried out the gui which build they tried, if I wanna regress back to a different build and start over I know which one to start at like build xxxx or whatever, im sure there are other advantages too. The versioning is only set arbritrarily to my taste and can be changed or eliminated altogether. Its just something I made after the fact and thought was cool.

Now one more thing, until I decide, hey this is my save point, the build and version mean absolutely nothing, its just ignored or whatever but when you wanna know how many times you built and ran your program and a prospective version number, its right there waiting. :)
I am from a Kazakhstan, we follow the hawk.

Offline keybone

  • Forum Regular
  • Posts: 116
  • My name a Nursultan Tulyakbay.
    • View Profile
Re: Build counters?
« Reply #16 on: August 12, 2018, 01:24:31 am »
I was thinking about this, and version numbers seem like they'd be something simple the precompiler could be expanded to handle easily enough.

$AUTOVER:ON|OFF <----  new precompiler flag which sets an internal variable.  Run and compile and all it'd need do is increment that variable and self-edit that line to reflect the change.

Compile once, with the flag set, and it'd automatically become $AUTOVER:ON 1.  Compile again and it becomes $AUTOVER:ON 2...

(Of course, if the flag was set off, it wouldn't alter or increment that variable.)

Tie that variable in as a set constant and then you can use it however you need in your program, such as:  PRINT "Current build number #"; _VER

Should be a simple enough type fix, and it's one I'd do for us, if there'd be enough interest in that type of functionality.

I would be interested in possibly using it depending on exactly how it was implemented.

So are you saying you turn $AUTOVER: ON and set it to a constant in your program, so when you build it increments that constant rewrites it into the source and it remains there until you turn $AUTOVER: OFF and delete the constant?
I am from a Kazakhstan, we follow the hawk.