Versioning scheme

[lgromanowski]

Would anyone object if we change our versioning scheme again?

Currently we are using x.yy. I would prefer the major.minor.release variant instead. Its more flexible and also has the release component, which is missing in our current scheme. The next release would be 0.9.0 and the one after that 0.10.0. I know someone mentioned that this might confuse some people, but honestly how hard can it be to understand this scheme?

Please note, that both schemes previously used are compatible with the one I propose (the leading zeros in 0.07 and 0.08 would just be redundant).

Also, can we drop the codenames? Looks like pointless silly fluff to me.

We can drop the codenames. I think codenames are for PR and secrecy, and an open source community project doesn't really lend itself to those behaviors.

I like three components, as well. Right now we are working on 0.09, and if we will be keeping a strict schedule (probably not a a good idea) then the third component will be required because you'd have to stop to get a release done.

Then again, another case for it would be if we make progress in such a way that we'll need to make more finite builds to mark progress...

To be honest, it has to fit the amount of work we can do - I suppose the three components works fine either way. It certainly clears up which build one would be working with and helps returning community members know what they re getting.

So I guess I say yea to it.

I'm only fuzzy on how we collectively increment the build revision...

Looks like pointless silly fluff to me.

Yup. Thats right. But I love silly fluffy things

Anyway lets just quit this.

Currently we are using x.yy. I would prefer the major.minor.release variant instead. Its more flexible and also has the release component, which is missing in our current scheme. The next release would be 0.9.0 and the one after that 0.10.0. I know someone mentioned that this might confuse some people, but honestly how hard can it be to understand this scheme?

It would be good if you put easy to undestand conditions for new major version (like "completed one big milestone + builded on windows and linux + no silly bugs open").

It would be good if you put easy to undestand conditions for new major version (like "completed one big milestone + builded on windows and linux + no silly bugs open).

I tend to think of it as a kind of clock.

The major version is the ultimate in finality. It's fairly obvious that major, project-mission-defining features go in here. It's unlikely that we'll go to 1 to 2, for example.

Minor versions would be something like incremental adding of features or major fixes. They eventually lead to a major version.

Revisions are a snapshot in time - they move fast on some projects (Blender3D) but, mark clear points where changes have been made and also mark progress.

It would be good if you put easy to undestand conditions for new major version (like "completed one big milestone + builded on windows and linux + no silly bugs open").

Condition for major version 1 (a.k.a. 1.0.0): complete replacement for the original Morrowind.exe. Nothing changed here.

Minor versions would be the milestones as before. A release would be a correction to a previously released minor version. Let's say we screw up 0.9.0 so badly, that it isn't usable. Then we could release 0.9.1 with the bug-fixes.

Really, nothing changes for now. It will just look slightly different and offer us more flexibility later.

ah, ok. Minor change then.

Using a three part version number sounds good to me.

I'm only fuzzy on how we collectively increment the build revision...

This is about distinguishing and keeping order among officially released packages, not all individual builds made by everyone.
Generally incrementing the version would be something someone does once per release. It gets committed to the primary repository and as everyone else pulls from there they will get the change.