Build counters?

[keybone]

Does anyone use build counters in their code?

I never did but I wanted to start and this is the one I came up with:

EDIT: Optimized slightly

Code: QB64: [Select]

1. FUNCTION buildCount~&& (inFilename AS STRING)
2.     inFilename = LTRIM$(RTRIM$(UCASE$(inFilename)))
3.     OPEN inFilename FOR INPUT AS #1
4.     INPUT #1, numberOfBuilds
5.     numberOfBuilds = numberOfBuilds + 1
6.     OPEN inFilename FOR OUTPUT AS #2
7.     PRINT #2, numberOfBuilds
8.     CLOSE #1, #2
9.     buildCount = numberOfBuilds
10. END FUNCTION

[keybone]

Then I thought of generating my version number off of the number of builds:

Code: QB64: [Select]

1. FUNCTION generateVersion! (inBuildNumber AS _UNSIGNED _INTEGER64)
2.     generateVersion = ((inBuildNumber / 10) * 0.01) ' Version 1.00 = 1000 builds.
3. END FUNCTION
4.  

[keybone]

Does anyone use build counters in their code?

I never did but I wanted to start and this is the one I came up with:

EDIT: Optimized slightly

Code: QB64: [Select]

1. FUNCTION buildCount~&& (inFilename AS STRING)
2.     inFilename = LTRIM$(RTRIM$(UCASE$(inFilename)))
3.     OPEN inFilename FOR INPUT AS #1
4.     INPUT #1, numberOfBuilds
5.     numberOfBuilds = numberOfBuilds + 1
6.     OPEN inFilename FOR OUTPUT AS #2
7.     PRINT #2, numberOfBuilds
8.     CLOSE #1, #2
9.     buildCount = numberOfBuilds
10. END FUNCTION

I broke the one in the original post I think... :D

EDIT: seems to work until I add a parameter to the function and pass it to the OPEN statement :-/ (seems to want a string literal)
EDIT again: NOPE... It does'nt want a literal... It doesnt like being passed the parameter for some reason.

[keybone]

This worked:

Code: QB64: [Select]

1. FUNCTION buildCount~&& (inFilename AS STRING)
2.     DIM Temporary AS STRING: Temporary = LTRIM$(RTRIM$(UCASE$(inFilename)))
3.     OPEN Temporary FOR INPUT AS #1
4.     INPUT #1, numberOfBuilds: CLOSE #1
5.     numberOfBuilds = numberOfBuilds + 1
6.     OPEN Temporary FOR OUTPUT AS #1
7.     PRINT #1, numberOfBuilds: CLOSE #1
8.     buildCount = numberOfBuilds
9. END FUNCTION

[bplus]

Hi keybone,

2 comments (due to my ignorance of build numbers)
1. Wow! when I look at the unsigned _integer64 type you assigned to the function, expecting allot of builds?
2. Assuming you want to automate the call to buildCount~&&, when would that happen?
Actually, it seems that it would have to be called manually, so it would depend on human perfection to remember to update the number with a call, hmm...?

I think I am assuming these build counts are for bas file development? I could be completely off track.

Now I am wondering if the usefulness is worth the effort?

For me, when a bas file reaches a certain level of satisfaction, I bak it with date and time.

Am I completely off track with what build number is?

[keybone]

Hi keybone,

2 comments (due to my ignorance of build numbers)
1. Wow! when I look at the unsigned _integer64 type you assigned to the function, expecting allot of builds?
2. Assuming you want to automate the call to buildCount~&&, when would that happen?
Actually, it seems that it would have to be called manually, so it would depend on human perfection to remember to update the number with a call, hmm...?

I think I am assuming these build counts are for bas file development? I could be completely off track.

Now I am wondering if the usefulness is worth the effort?

For me, when a bas file reaches a certain level of satisfaction, I bak it with date and time.

Am I completely off track with what build number is?

The _integer64 is there in case there ever if a time that it needs to be that big.... Just in case as unlikely as it would ever be, because i would rather waste 3 bytes then ever have to change it. Its future-proof.

as far as usefulness goes, to each their own, its not really worth even thinking about, you might think its not useful but another person will...

as far as automation goes... This code was at the top of my project i was working on. May be buggy im tired and have been changing things all night but it still should give you the general idea. Here it is:

Code: QB64: [Select]

1. TYPE anInformation
2.     Title AS STRING * 5
3.     versionNumber AS SINGLE
4.     buildNumber AS _UNSIGNED _INTEGER64
5. END TYPE
6.  
7. DIM theInformation AS anInformation
8.  
9. theInformation.Title = "XGUI5"
10. theInformation.buildNumber = buildCount("BUILD.CNT")
11. theInformation.versionNumber = generateVersion(theInformation.buildNumber)
12.  
13. IF theInformation.versionNumber < 1.0 THEN
14.     PRINT theInformation.Title + " Version 0" + LTRIM$(RTRIM$(STR$(theInformation.versionNumber))) + " Build: " + LTRIM$(RTRIM$(STR$(theInformation.buildNumber)))
15. ELSE
16. PRINT theInformation.Title + " Version " + LTRIM$(RTRIM$(STR$(theInformation.versionNumber))) + " Build: " + LTRIM$(RTRIM$(STR$(theInformation.buildNumber)))
17. END IF

[bplus]

Hi keybone,

as far as usefulness goes, to each their own, its not really worth even thinking about, you might think its not useful but another person will...

Usually, if I don't see something as useful but ask, the person gives me a clue as to how they would use it, and then (usually) things makes sense to me.

It is very much worth it to me to see how the other person is thinking, I might learn something that comes in useful later on... who knows?

I confess I am still in dark as to how you would use this count? Is this counting code run every time you run the bas file or are running from a bas project manager file that oversees a bunch of bas and other files.

If these questions and comments are annoying, forget about it, my aim is to understand NOT annoy.

[keybone]

Hi keybone,

as far as usefulness goes, to each their own, its not really worth even thinking about, you might think its not useful but another person will...

Usually, if I don't see something as useful but ask, the person gives me a clue as to how they would use it, and then (usually) things makes sense to me.

It is very much worth it to me to see how the other person is thinking, I might learn something that comes in useful later on... who knows?

I confess I am still in dark as to how you would use this count? Is this counting code run every time you run the bas file or are running from a bas project manager file that oversees a bunch of bas and other files.

If these questions and comments are annoying, forget about it, my aim is to understand NOT annoy.

Dude, u weren't annoying me. Its all good...


this is how im using it...

each running .bas file in this thing updates the same build file, the same version number... So if I press run in the ide, and I have 2 open, and I press run in the other one too, the that will be 2 builds... every time you press run, in increases the build number.

The usefulness is simply this, it prevents you from arbitrarily having to assign your program a version number, no more my program seems mostly done ill call this version 1.0.... the way i have it set up version 1.0 is build 1000 (which is probably more than enough. i began count automatically from the very beginning).

It simply ends up like this: one day ill release something it will be something like X-GUI 5 Version .70 (Build 700)... Or i can just call it Build 700 or whatever. On the flipside, when the program is actually at a 1.0 state, I can change the version back to 1.0 and adjust the number of builds required, then from that point on it might take 778 builds to go up a major version, or 1043 for that matter. I could change it again and again and again, and it doesnt really matter, it will never conflict (i.e there could be version 1.0 (build 1000) that is nowhere near a real 1.0 state... When it finally does get to a 1.0 state at maybe build 1553, i can just change that to version 1.0 Build 1553, it could be known that 1.0 build 1000 was crap :D and is now like version 0.66 Build 1000 now. :D


Oh also, this will count also every time it runs... In order to stop that, you have to either remove it, or set a flag that signifies youre running not building. i might find a way to do that automatically.

[SMcNeill]

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.

[bplus]

Thanks Keybone for going over it again, I've got it now (I think) what you are calling builds, I would call runs and now I understand the maximum type integer allowed. :D Ha! in a day I'd blunder my way to version 1 if that's 1000 runs.

Yes, Steve that is an interesting idea. Not sure I'd want to see that number? ;-))

[SMcNeill]

Thanks Keybone for going over it again, I've got it now (I think) what you are calling builds, I would call runs and now I understand the maximum type integer allowed. :D Ha! in a day I'd blunder my way to version 1 if that's 1000 runs.

Yes, Steve that is an interesting idea. Not sure I'd want to see that number? ;-))

I don't think that number would ever get too large; it'd only increase in your program when you compiled, not when the program was run.

Of course, you might want to set it OFF if you know you're going to be doing multiple compiles for debugging purposes, or whatever, if you don't want it to increment a dozen times on you.  ;)

[FellippeHeitor]

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.

[bplus]

I agree a version number should reflect a significant change of quality. But there is a relation between number of builds (maybe not so much runs) and quality change, quantity is a quality too.

While thinking about this, I am kind of amazed how QB64 has reflected version numbers with keywords and _keywords!

[SMcNeill]

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.

Not really, if you think about it as two different things: version number vs. build number.  Heck, even QB64 does something similar now, with version 1.0/1.1/1.2 and repository build 88/89/90...  The programmer could still set a version number for their program, which would be completely separate from the automated build number. 

[FellippeHeitor]

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.

Not really, if you think about it as two different things: version number vs. build number.  Heck, even QB64 does something similar now, with version 1.0/1.1/1.2 and repository build 88/89/90...  The programmer could still set a version number for their program, which would be completely separate from the automated build number. 

Agree to disagree. QB64 build numbers are manual and must be changed consciously too, so much that we decided not to make changes to it in development builds.