SRL Archive - Senior Discussions and Debates

Last night I was looking into configuration and change management, which brought me to the thoughts of how do we actually version our scripts? I never saw any formal process of doing this? Is there such a thing? If not, I've got an idea that could help us doing some proper versioning…

.1 per function added
.01 per function edited

So each script version would have 10 new functions added to it or 100 changes done or a combination of both. Of course this might mean that the first release is not version 1.00, but when is it really?

And also keeping track of the changes is just simply good industry standards and considering that many people learn from here and move on to the real IT world with real IT companies this might be a useful skill to teach while they are here.

My question remains is there any formal widely recognized better way to do it, or is this a perfectly acceptable method by IT standards? (question goes out to anyone who is actually really properly into IT unlike me, information manager with programming as a side hobby every now and then)

As far as I'm aware there is no "this is the right way to do it" for versioning. Some places do it by the date when the change is committed, others do it by commit number, others just slap an arbitrary number at the end.

Depends on project.

first digit, the major version.

0 = not yet ready for the majority of users(alpha, beta version)
1 = no longer an alpha or beta version. All functionality the project leader wanted is in the project.
2+ = major overhauls, big system changes, complete rewrites. This number shouldn't be changed a lot.

everything behind that is also up to the project. Definitively not by the functions added or edited.

The second digits are usually major additions, often people use it like this, 1.11.00, when it becomes bigger then 9.

after that minor changes/ bugfixes. What is major and what is minor depends on the project. An operation system might call 10.000 new lines of code minor, but a runescape bot will probably call that major, if not a complete overhaul.

edit: source: an IT class somewhere in the back of my memory.

as for number of functions, my reasoning there was work packages, and how each work package has its milestones and so on - I guess milestones could also be a good method for versioning?

version 1.25 would be version 1 plus a quarter of the milestones for version 2

or from the previous function thingy, would be version one plus 2 functions and 5 edits
Of course this number by function could be misleading because it might just be a very small function or you might be breaking down a function into two and so it would seem like a lot of work was done due to the version number when in fact very little changed.

Do you guys feels that having an established versioning method at SRL would be useful / helpful / beneficial?

I think it will be very helpful when we get the script manager *yawn* :p

From: Sir R. M8gic1an
Do you guys feels that having an established versioning method at SRL would be useful / helpful / beneficial?

I think so; given any time when I look at code, if I were given the option to see a version number that I understood how the coder formatted their version, I'd much like to see the differences and progress that have been made from one version of their code to the next. :)

~Lj

From: Sir R. M8gic1an
Do you guys feels that having an established versioning method at SRL would be useful / helpful / beneficial?

Not really, no. As long as it's numerical, and it's not decreasing, then it's fine in my books.

From: Daniel
Not really, no. As long as it's numerical, and it's not decreasing, then it's fine in my books.

This since it is just scripting. If the person plans on going into IT, it is best to learn Major/Minor versions rather than: "Alpha, Beta, Release, v#.##".

http://en.wikipedia.org/wiki/Software_versioning

I'd say let's make a standard, tho it is up to the script developer ultimately.

I think I'm right on the 4 day edge before technically "grave-digging," and am unsure what had become of this topic; however I wanted to also input the possibility of:

Major:Minor:Build:Revision, numbers of course, and much alike the ones listed by MasterBB. Credit to a Visual Studio project for idea/use.

Cheers,
Lj

From: Le Jingle
I think I'm right on the 4 day edge before technically "grave-digging," and am unsure what had become of this topic; however I wanted to also input the possibility of:

Major:Minor:Build:Revision, numbers of course, and much alike the ones listed by MasterBB. Credit to a Visual Studio project for idea/use.

Cheers,
Lj

I doubt it matters in this section, if it or any other bumped thread is classified as a gravedig then I'd surely argue against it.

I also agree with what masterBB said; this seems like an efficient way to do it.

For the sake of consistency (at the cost of reviving a few month old thread), check out http://semver.org/

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

This is how I manage all software I maintain.