I would like to add version numbering to the Distro. It would take the form of a major version number and a minor version number. I am thinking something like MMM.mm where "M" is the major part and "m" is the minor part, 0.99.01 for example.

I have a few questions though.

What constitutes a minor version release and conversely, a major version release?
Here are my thoughts:
Minor version releases would encompass at least these items:
Bug fixes

The addition of new INC or SRC (possibly new commands). Files that do not affect the current operation of the Distro, ie. no need for users to modify any existing packages they may have added to work with the new files.
The addition of a function added to an INC file, for example the addition of ThisIsMe's functions to the math.inc file that return dice strings when passed min and max values.

Maybe minor tweaks to cfg files as well. Again as long as they don't require mods to packages someone may have added. Although the cfg tweaks might be hard to determine whether mods are necessary or not depending on the cfg file. I'll have to think about cfg tweaks...

What constitutes a major release?
My thoughts: a new package added. Especially if it's a large package or it adds some major feature such as a new spell system.

Anything that might require changes to optional packages a user has installed. Such as the necromancy package that has it's hooks in a couple of areas already.

Major package rewrites or reorganizations. An example comes to mind that I am working on right now, attributes. I am moving all attribute related files to an attributes package. They were all over the place before.

Is there any way to automate a versioning system?
I would assume not if we are going to use somewhat subjective criteria such as I listed above.

Or should we just do minor version bumps with each commit unless the person making the commit feels that it is worth a major version bump?
This, I assume, would be much easier to automate if a version system can be automated.

I would like to hear your thoughts. Especially from developers who have had to work in an environment were versioning was used.

I'm not so sure that versioning really applies to the Distro unless you're planning on periodically packing all the scripts into some sort of installer.
As its currently an open source software on the GIT anyone can get the latest versions.

I guess I'd need to know why you would want to look at adding some sort of versioning to the Distro to understand if it would actually be helpful. If its to try and help people who might be running a certain set of scripts so you can understand why a particular bug is happening, in most cases if the bug existed in the scripts previously it still would, unless its been patched or re-written, in which case the answer to them would be "update", you'd also run into issues with trying to help people based on the assumption they are running a non-modified version of the Distro at that specific version control.

Alternatively, do version control and release ecl files only. that way people can't modify it and you should always be able to help them based on that version.

Otherwise i think version control can get a bit messy with the way GIT versions work. Just my 2 cents

You make some good points. Though I have to take issue with the "open source code" not having version numbers or maybe not needing a version number. The very emulator eScript runs on is open source and it has a version number. I have seen other open source projects that have version numbers. Lazarus,, the object Pascal environment I am using and its underlying Free Pascal software are open source and they have version numbers..

I listed examples of cases where I felt versioning might apply..

Anyway maybe just a release date attached to the Distro updates will be enough. Oh and yes I do believe that the Distro and Core should be available as a zip and or installer from POL's website. You should not have to leave the site you came to for the software to get the software. Besides some people might just want to download a working emulator to set up a way for their friends to play UO, Then maybe they will get into scripting but their original intent was just to play a game. Not everyone is geeky enough to install Visual Studio, go to Github , download the Core source code, compile it, go to the Distro repo, and download that. It's bad enough that they have to go through the burden of configuring POL before they can even run it. Maybe what we, the developers, need is a reality check.

Forget everything you know about POL atleast try. Then go through the process you would have to if you are a new user. Remember, you know nothing about setting up a POL server. Go through the process of downloading, installing, configuring and launching POL. After you've done that successfully go grab ServUO and do the same thing using their installer and tell me which emulator you want to use..

I am sorry but for more years than I can remember POL has been a mess to set up and it seems like no one wants to change that. Frankly it's annoying. Why do you think I spent the time resurrecting my Configurator?

Maybe you're right. I should include a completely configured and COMPILED POL installation!

I am sorry Dev for letting my frustration with the unnecessary complexity of getting POL up and running get directed at you. Please accept my apology.

Version+CommitId

After talking to Nando I have decided to use the current Core version with the date appended to that as a versioning number for the Distro zip and installer files. As it doesn't get updated very quickly that will do an adequate job for now. We will not be versioning the repo.

Cool I agree with that