Feature: Format Specifier for 'Changeset'

Dec 8, 2011 at 1:10 AM

We utilize both build and changeset numbers in the following format:

Major.Minor.Build.Changeset

Unfortunately I don't see any mechanism for specifying Changeset, a "C" parameter would be perfect, providing us with a format such as the following:

4.5.b.c

A question may be "What value should this provide?" and I feel this should provide the changeset of the first workspace defined in the build process.

This functionality is currently implemented as a custom/internal versioning activity, however, I would like for us to adopt 'TfsVersioning' instead because I feel that it offers more useful features than what we currently have implemented, which is blocking our ability to adopt TfsNugetter.

-Please- consider implementing this feature, I would be pitching TfsVersioning and TfsNugetter right now if it was able to encode Changeset into our version numbers. Perhaps I'm missing something and it can already be done? If so, do share! :)

Thanks!

Shaun Wilson // Senior Software Engineer // Corp Apps // Blizzard Entertainment

 

Coordinator
Dec 21, 2011 at 11:18 PM

When designing the last set of updates, I opted out of including changesets mainly because in certain environments (larger environments that is) you can run out of room with no indication.  In other words, when the changeset number reaches 65535 you're done.  They won't work after that because of the size of the integer holding the value in each of the major, minor, build, revision numbers.  Case in point: if you look at the source for this project you'll see that the changeset numbers are well over 90,000.  Numbers that high inserted into an assembly version would come out looking nothing like the number going in.  You would then have to detect the problem followed by coming up with a new approach for your version numbers.  Of course you could build in error detection in the build workflow when the number goes over the limit but even with that you still have to come up with a new versioning scheme.



Personally, I rather like including the build number included in the assembly informational version.  This gives you the all encompassing label applied to the code that was used to build your application rather than just getting close with a single changeset number (especially, when there could be many used to create your app).

Mark

Dec 21, 2011 at 11:46 PM
Agreed and ill be discussing our current approach further with leads. Thanks

-- sent from mobile

Sent from my Windows Phone

From: marknic
Sent: 12/21/2011 3:18 PM
To: mrshaunwilson@msn.com
Subject: Re: Feature: Format Specifier for 'Changeset' [TFSVersioning:282211]

From: marknic

When designing the last set of updates, I opted out of including changesets mainly because in certain environments (larger environments that is) you can run out of room with no indication. In other words, when the changeset number reaches 65535 you're done. They won't work after that because of the size of the integer holding the value in each of the major, minor, build, revision numbers. Case in point: if you look at the source for this project you'll see that the changeset numbers are well over 90,000. Numbers that high inserted into an assembly version would come out looking nothing like the number going in. You would then have to detect the problem followed by coming up with a new approach for your version numbers. Of course you could build in error detection in the build workflow when the number goes over the limit but even with that you still have to come up with a new versioning scheme.



Personally, I rather like including the build number included in the assembly informational version. This gives you the all encompassing label applied to the code that was used to build your application rather than just getting close with a single changeset number (especially, when there could be many used to create your app).

Mark

Apr 21, 2013 at 10:37 AM
Could that be added anyways, with a big warning? :)
We are not getting to 60k changesets in the next 5 years...

Michel
Apr 22, 2013 at 8:04 PM
I've seen the limit broken at every corp I've been employed at, Myspace saw over 100k check-ins in as little as 2 years.

It's true smaller shops may never have an issue, though.


- Shaun


Apr 24, 2015 at 11:52 AM
Any news???