bricksync states incorrect version of bricksync

[cwmcd]

just loaded up the 1.7.2-3 version of bricksync.

in the console it states that it is running "software version 1.7.1 - apr 2 2021"

[ZZJHONS]

Yeah, I was just now checking where it needs to be updated.

And I think it is just this file: https://github.com/ZZJHONS/Bricksync/blob/master/bricksync.h

#define BS_VERSION_MAJOR (1)
#define BS_VERSION_MINOR (7)
#define BS_VERSION_REVISION (1)
#define BS_VERSION_STRING "1.7.1"

But I don't want to break the code doing so, don't know if it would affect anything either.

But changing just the BS_VERSION_STRING to 1.7.2-5 might be enough for the next release.

If someone can have a look it would be appreciated :)

[beaverbrick]

I tried just changing those strings when I updated the colortable.c, but it throws warnings when running the program.
There must be some checks within the program to check which version is running.
I just reset the strings again as I didn't want to break anything.
The warning message was about running a "version from the future".
I didn't get round to digging further and finding where the checks are.

[beaverbrick]

Finally got round to sorting this out.
Modified the program so that it doesn't communicate with the bricksync server... which eliminates the version warnings and also the message broadcasts that appear.

Regarding the version displayed... this is hard-coded and although there's probably a way to automate it with github, I honestly don't know how. I don't envisage bricksync being updated that regularly so I can just change the version number as and when required.

But... how does the github.run_number work?
Looks like there is some code to automate the version as 1.7.2 + -github.run_number.
So if we create a new version now, what would the run number be?
I just need to make sure the code and github match each other.

[cwmcd]

Finally got round to sorting this out.
Modified the program so that it doesn't communicate with the bricksync server... which eliminates the version warnings and also the message broadcasts that appear.

Regarding the version displayed... this is hard-coded and although there's probably a way to automate it with github, I honestly don't know how. I don't envisage bricksync being updated that regularly so I can just change the version number as and when required.

But... how does the github.run_number work?
Looks like there is some code to automate the version as 1.7.2 + -github.run_number.
So if we create a new version now, what would the run number be?
I just need to make sure the code and github match each other.

i'm assuming that the program probably does a check of the file at github, does a compare and if the files are the same sets the version to the current number of the version at github. otherwise it displays the version of the update and notifies you of update. possibly why you can't actually find where it's coded?

[beaverbrick]

@ZZJHONS
When you create a new release, do you set the version?

I've updated the program to 1.7.4.
I've also updated the matrix to name the downloaded zip file as 1.7.4-x.

[ZZJHONS]

@beaverbrick maybe we can copy the way @rgriebl's BrickStore does it:

https://github.com/rgriebl/brickstore/search?q=BUILD_NUMBER

PD: The version is hardcoded I think, the build number is a different number that is auto generated once a commit is done.

[beaverbrick]

@ZZJHONS Yes, BrickSync's version is hard-coded in the program.
Unfortunately, I just don't know enough about github to automate it.
The program is rarely going to change, so I figure it's probably not worth spending a lot of time on.

[cwmcd]

"the program is rarely going to change".....so what you're saying is that there is plenty of time to tidy this up right? ;P

[Brickadoon]

I've updated the version to 1.7.4-12 in the bricksync.h file and tested it on my Win64 build. Doesn't complain about version numbers...

#define BS_VERSION_MAJOR (1)
#define BS_VERSION_MINOR (7)
#define BS_VERSION_REVISION (4)
#define BS_VERSION_STRING "1.7.4-12"
#define BS_VERSION_INTEGER_ENCODE(major,minor,revision) (((major)*10000)|((minor)*100)|((revision)*1))
#define BS_VERSION_INTEGER BS_VERSION_INTEGER_ENCODE(BS_VERSION_MAJOR,BS_VERSION_MINOR,BS_VERSION_REVISION)

[craigpoma]

@ZZJHONS - With latest build - I think you can close the Issue request - If I am reading the intent of it properly. You can now specify build number with the command-line / compile-time (-DBS_VERSION_BUILDTIME) option. Major/Minor/Revision are still fixated in the code - but the -BUILDTIME is configurable.