[sammp]

If the title wasn't clear, how do you come to the conclusion that your version is v1.24 for example.

I do it like this:

Stage.Major.Minor.Bugfix Release

I also structure the stage as so:

0 = Development/Alpha
1 = Beta
2 on‌wards = Full Release

So right now, my gamemode's update number is 0.1.4.8. Stage 0, major 1, minor 4, bugfix 8. It's good for tracking the update. How do you guys do it?

[Luis-]

At the minute mine is in the development stages, but once it's fully finished it'll be version 1.0.0.

[JaydenJason]

Quote:

Originally Posted by Luis- At the minute mine is in the development stages, but once it's fully finished it'll be version 1.0.0.

Not really what he asked but okay,

Mines similar, only bugfixes are marked with a "-" for me, so

Stage.Major.Minor-Bugfix

[PowerPC603]

I'm not using version numbers.

My first script was PPC Trucking.
But since most people had too many errors when they decided to change/add/remove stuff while they had not enough experience in scripting (they forgot to move comma's and ; signs), I started on a new script that's being written from scratch, with only bits and pieces from the first script.

That way the first script got named PPC Trucking V1, while the new script will be PPC Trucking V2.
No sub-versions or whatever.

The first script was released one day and didn't have much features.
Upon request, I added new stuff and even added 2 additional classes and more features along the way and I re-uploaded it all again and announced a new updated script inside my topic.
But it didn't receive any additional version indication or whatever.

[sammp]

Week numbers is quite a good idea. I might remove the bugfix part for now because my gm is basic and it constantly has bugs (because I try some weird ass shit with the script), and it's pretty useless for a sa-mp server.

If it's software, I follow template of Major.minor.bugfix.build e.g 1.3.4.39 etc...

I have a strong feeling most people just put a random number like v1.2.3, which is bad because I look at the version number before I join a server to check if there's enough updates for it to 1: be worth playing & 2: check if it's being actively developed.

[TittyMcSwag]

Mind explaining what stage, major, minor and bug fix is? How do you number it?

[sammp]

Stage of Development
Major update
minor update
total bugfixes on update

1.4.4.928

Stage 1, Major 4, Minor 4, Bugfix 928

[Jonny5]

i tend to use the date as the build number.
when i start any software i give it a major version of 0 as its not released yet.

so for me
Major - this would be a substantial amount of code changes to change this number
Minor - this could be features added but not changing the code base to much
Build - i use the date mm/dd/yyyy

ver 0.1.05062015 is how a new project version might look.
when my project has reached a release stage it would look like ver 1.0.05062015

most projects i keep a "changed log" listing any changes i made during the coding session.
at the end of any giving program session i edit a "todo" list
to help keep clear on what is done and what needs done.

[MP2]

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

I use the basic Major.Minor.Build.

[Luis-]

That's how I do it.

[[HLF]Southclaw]

I'm surprised no one has posted Semantic Versioning yet (I mentioned it earlier) it's quite a robust system with a clearly defined set of guidelines followed by lots of projects both homebrew and large scale!

Extract from the summary:

Quote:

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.

[sammp]

Quote:

Originally Posted by [HLF]Southclaw snip

i do it similarly

[ArchB42]

I only use builds. Dev version is Build 0. Initial version is Build 1. The 25th update is Build 25. Nothing special, it just helps me to keep a track on which version had a problem (ex: this bug was fixed in b30).

With some development tools I know when I applied an update and what was inside that update. I don't need anything fancy like major.minor.bugfix or whatever.

[sammp]

Calling it a build is wrong, because calling it a build is basically in pawn every time you compile it - Compilation is only one part of a build as well.

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

Just call it Update if you don't really know how it works.

Also, you'll regret not having a major.minor.bugfix if your server goes big and you need more than one developer. IMO if you're developing a script, stick to the rules of versioning and don't just call it anything

[Luis-]

Seems like way too much work to be honest. Although I am really stupid when it comes to stuff like this.

[sammp]

LS-RP is 5.4.150

I think theirs is Major.Minor.Build/Bugfix


It's a lot to keep up with, but it's good practice for when you start developing API's when this is absolutely essential

[ikey07]

each time I put on updates, I add 1, so its 1.0.0 1.0.1 1.0.2 and so on

[Luis-]

Quote:

Originally Posted by ikey07 each time I put on updates, I add 1, so its 1.0.0 1.0.1 1.0.2 and so on

This is what I prefer to do. It's much simpler to those who don't know a thing about script version names.

[ArchB42]

Quote:

Originally Posted by sammp Calling it a build is wrong, because calling it a build is basically in pawn every time you compile it - Compilation is only one part of a build as well. http://en.wikipedia.org/wiki/Software_build Just call it Update if you don't really know how it works. Also, you'll regret not having a major.minor.bugfix if your server goes big and you need more than one developer. IMO if you're developing a script, stick to the rules of versioning and don't just call it anything

Well. I have a private repository where I commit bugfixes. The repository is the dev version, nothing less, nothing more. I don't use branches.

When it comes to versioning, a version only gives a name to a script release (when it's uploaded to the ftp). So in my case that's only helpful for bug reports history and also to show players that we made an update (again, just helpful because it gives a name to a release).

In my case I really don't see the utility of major.minor.bugfix but I agree it's something good to do if your project gets bigger. However I honestly don't think it's useful for a one-dev SA:MP 50 slots server.

[Ahmad45123]

I was versioning the same way everyone do like Major.Minor.BugFix, And I was using this as I always back up my gamemode in folders with the version name..
But after I knew git.. I converted to it which is alot more better to keep track of changes and to always have backups if u screw something up.

So I just changed the way I version it cuz it was a headache:

Quote:

Originally Posted by ikey07 each time I put on updates, I add 1, so its 1.0.0 1.0.1 1.0.2 and so on

But I increment the BugFix once its a BugFixes only update and increment the minor once its a major update that contains new `big` features.

And increment major once minor reaches 9.

That's really alot simiplier way.. I use it now cuz it isn't really important to me from a development side because I have got the commit number auto generated for each commit which is alot better.