Sequence file Version number. How to prevent the automatic resetting build version number whilst auto-incrementing revision number?

[MimiKLM]

Hi,

I've got my environment set this way that each save of the sequence file increase the revision part of version number. However, during that increase the build counter is reset to 0. How to prevent it?

TS 4.2

[Rhys - AE]

Hi there,

I've been hunting around TestStand but I'm not absolutely clear on what you mean by the 'Build Counter'. Perhaps a ascreen shot could help explain?

Hoping to help!

[MimiKLM]

By build counter I mean the build part (less significant one, most right one) of the sequence file version number.

 

[Rhys - AE]

Hello again,

I took a dig through the TestStand 4.2 help and found this article. Is this the method you are using to increment the version number? And if so, do these numbers help?

Thanks!

[MimiKLM]

Yes, 

That is what I'm using. My value is set to 3. And it works fine, but I have something extra with that. Along with auto incrementing Revision component, the Build component it reseted to 0. I don't want the build component to be reseted back to 0 when the Revision component is incremented.

Is there any chance to disable that extra thing?? 

[Rhys - AE]

Hello,

I got in touch with our resident TestStand guy as I couldn't satisfy the question myself.

I always hate giving the answer; but it is unfortunately "just the way it is". The revision, build, version etc format will always overwrite the least significant bits to the one we increment and there isn't anything in the API to avoid that behaviour.

It comes down to opinion when you consider which is more or least significant, revision/version/build etc, but the order TestStand has them set out in is just the way NI have interperated it.

Sorry to bear bad news, but all the best with your application!

[~jiggawax~]

Mimi,

It is pretty common practice in software revisioning to reset a minor number to 0 when a major moves up 1.  There are many different schemes out there.  If you google or bing software versioning schemes you'll see what I'm talking about.

So looking at it from left to right:  Major.Minor.Revision.Build = 0.0.0.1 

if you change the Revision it would be expected that anything to the right (in this case Build) would reset to 0.  0.0.1.0!

Let's say your version is 8.34.56.23.  It would make sense that if you were to change the Major number (which means a Major release) to 9 then your version would go to: 9.0.0.0. 

A version number is just a unique way to tell someone which specific software you are using so it really doesn't matter that it resets to 0.  Although it makes sense because if you kept your build number sequential and didn't reset it then it would get outrageously larger which would be more annoying than anything. 

Again this is common accepted practice in industry.

Good Luck,

[snowpunter]

If you google or bing software versioning schemes you'll see what I'm talking about.

Jigg is contractually obligated to mention the MS search option while the rest of us just say 'google it.'

[MimiKLM]

Hi Jig,

The practice you've presended is maybe the 'pretty common' but not only one. For example please find out how the TortoiseSVN is being versioned. In this SW the build component is never reset.

I need this functionality to secure the correct dataset recognition in our data mining software. So, it would be good if the next version of TS could have the property to control shall the build version number to be reset or not.

Current solution assuming one way of doing the versioning, dissmising other valid style. I believe there is no reason behind the current implementation of vesioning and there will be no objections to release it in future.