Rock Solid Stable - Release Time

[softcoder]

We have been testing 3.8.0 all week and I just wanted to say, that network play is finally incredibly stable! We are able to play cross platform games with 5-6 humans and 2 CPU's for 60 minutes with no lag and no out of synchs. We will be releasing likely tomorrow (Saturday) and look forward to hearing about your experiences with 3.8.0.

Enjoy!

[titi]

All good here too so far, but I want to say that we should think about calling the version 3.9.0 .
We accidently called the beta 3.8.0-beta1, but we decided a while ago to only make the first two fields relevant for joining games.

This will result in beta1 people beeing able to join the release version causing trouble. What do you think ?

[filux]

In my opinion it isn't a good idea, because versioning is somewhat a part of "building trust" and it should be important to MegaGlest. We should always use "unified/semantic versioning", what means now should be stable version 3.8.0 or in the last resort 3.8.1.

...We accidently called the beta 3.8.0-beta1...
This will result in beta1 people beeing able to join the release version causing trouble...

In my opinion it is a bug 3.8.0-beta1 should be compatible only with the same 3.8.0-beta1, 3.8.0-beta2 only with 3.8.0-beta2, and only stable releases like 3.8.0 should be compatible with 3.8.1...3.8.4...3.8.9.

[tomreyn]

Code: [Select]

<tomreyn> 1.2.3 and 1.2.4 should be compatible, but 1.2.3-alpha1 and 1.2.3-alpha2 should not be not be. Nor 1.2.3-alpha1 and 1.2.3-beta2, nor 1.2.3-alpha1 and 1.2.3.
http://semver.org/

[titi]

Ok, finally we made it! From my point of view we are ready and stable!
Releasetime!
( only tomreyn must give his ok )

... and don't forget to mention the updated romans in release notes in case you did not do it yet ;-)

[ctz]

So I just tested 3.8.0-beta1 and 3.8.0 joining by setting

Code: [Select]

const string glestVersionString = "v3.8.0";in source/glest_game/facilities/game_util.cpp for current svn (r4824).

beta1 can try to join 3.8.0; upon joining, beta1 gets an error "Invalid message type: 76", becomes very slow, and gets disconnected.
If 3.8.0 tries to join beta1, the beta1 host gets "Invalid message type: 76", becomes very slow, and then crashes; 3.8.0 gets disconnected and goes back to the main lobby.
(I tested on gnu/linux, don't know if crash also happens on windows.)

So 3.8.0 and 3.8.0-beta1 can never be in the same game together, although they can try to join each other and it is very inconvenient for (only) the beta1 side.  Is that good enough to keep the 3.8.0 number?  If possible, maybe a note can be put into the masterserver message telling beta1 users to upgrade.

[softcoder]

The problem is that we switched to a 2 digit version system after 3.7.0, but we did not properly reflect that during the beta's for 3.8. We SHOULD HAVE set version #'s to 3.8-dev, 3.8-beta1, 3.8-beta2 and finally 3.8 on release. I think we  will need to set the release to v3.9 to correct this and then remember to use the 2 digit system in the future. This was intended so that the 3rd digit is just a marker indicating minor changes but still compatible. I have added unit tests in svn to describe how versioning is expected to work for future reference.

[MJR]

Any idea on when the new final version will be released?

[softcoder]

We are preparing a release v3.9 tonight (GMT -8) or tomorrow. All is in great shape, and testing has been fantastic. v3.9 will be a classic for a long time to come.

Keep watch for release details.

[Omega]

http://semver.org/

Is there any plans to use this? I'm a fan of semantic versioning because of its consistency (actually, I stole this link for one of my own software projects).

[titi]

Semantic Versioning 2.0.0 does not really fit to MGs  needs. Its more made to develop libs, not something like MegaGlest.
While we are developing nearly every tiny change breaks compatibility with older versions, so the first number would count up VERY fast, and there is nothing we can do about it. So doing it the way they suggest it there is not a good idea in my opinion.

But we should stay with the same naming scheme and I suggest the following:
We use the MAJOR.MINOR.PATCH system in general, but we need to change the meanings a bit to fit our needs. (So next version would be 3.9.0).
If we now make a patch which is fully compatible we call it 3.9.1
If we change something what is not compatible we name it 3.10.0

But the problem we have is how to name development versions and betas, alphas and so on:
As we already saw, naming the last beta 3.8.0-beta1 was not a really good idea with the current way of versioning, as it would mean this version would be compatible with all 3.8.x versions we would release. but how to call it ?
3.8-beta1.0 would work but is very unusual.
So I suggest to make everything with a non numeric letter inside incompatible to everything!
So for all real releases we use the typical MAJOR.MINOR.PATCH behaviour , but for everything with -beta -alpha -dev or whatever inside we force a full match of the whole version string.
This would fit perfect to our needs while developing and ends up in a versioning system which is "world" compatible,

What do you think ?

(update: this would even allow us to call the next version 3.8.0 as we initially wanted it )

[tomreyn]

Thanks for making your mind up on it. The main argument you discuss against adopting semantic versioning is that the major version number would increment "VERY fast". Now since we are trying to be reasonable and "world compatible" - how any releases are there of MegaGlest per year? One or two, maybe three. However, a relevant part of these will be alpha or beta releases, so it's really just one or two major releases per year. And even then, if it's version 232.0.0 then that's fine with me, since it's still a very conclusive statement.

I agree that MegaGlest (as a game or game engine) is not a piece of software many other softwares depend on (Annex does, and maybe other games will in the future, but that's not too much), so it's not too important for MegaGlest to be extremely strict about its versioning scheme.

This said, the approach you suggest (and which we discussed before) would seem like an important step in the right direction, so I think it would be a great improvement to adapt it.

I would keep 3.9.0 as the version string for the upcoming release, though, especially if the versioning scheme changes. It's perfectly OK to skip a version as long as it's documented in the changelog, and we have good reasons.

[filux]

...
So I suggest to make everything with a non numeric letter inside incompatible to everything!
So for all real releases we use the typical MAJOR.MINOR.PATCH behaviour , but for everything with -beta -alpha -dev or whatever inside we force a full match of the whole version string.
This would fit perfect to our needs while developing and ends up in a versioning system which is "world" compatible
...
(update: this would even allow us to call the next version 3.8.0 as we initially wanted it )...

...
This said, the approach you suggest (and which we discussed before) would seem like an important step in the right direction, so I think it would be a great improvement to adapt it....

^ I'm fully agree with both. 

...While we are developing nearly every tiny change breaks compatibility with older versions, so the first number would count up VERY fast, and there is nothing we can do about it...

How others doing it...

A lot of developers for this purpose have second "frozen branch", and commiting to it only backwards compatible patches and per some (short) time they doing based on this branch the next stable version e.g. X.X.0 > X.X.1,
... and again X.X.1 > X.X.2 and again ...

In the "first"/dev branch work takes place in parallel (to frozen branch) and it contain all patches backwards compatible & incompatible too and based on this branch after some longer time (as in frozen branch) is released new stable version X.0.X > X.1.0

I will add that these developers usually work in other version control systems than svn, where such wonders are easy to do, like e.g. git.

[Omega]

A lot of developers for this purpose have second "frozen branch", and commiting to it only backwards compatible patches and per some (short) time they doing based on this branch the next stable version e.g. X.X.0 > X.X.1,

That's what SMF and JQuery do. Both currently have a version 1.x and 2.x. The older versions only get bug fixes. However, I don't feel that's a good idea for MG: takes up too many resources and we want players to have the latest and greatest version.

[titi]

@filux all that can be done with svn too and we do it this way.

Also I already implemented it, the whole Version thing is delayed after release. I did not checkin and we now just look at the release the way we have it now . We will call the new version 3.9.0.

@softcoder:
in general about the first try of installers I tested:
MegaGlest-Installer-3.9_i686_linux.run:
- The i686 installer is much bigger then the 64bit one. there is a file called mgdata.tar.xz in it, which is not needed.
- all binaries are not stripped I vote to have stripped binaries without debug info in a release installer. ( the full size binaries can be provided with a pure binary package in case someone needs them)
- and don't forget to call it 3.9.0 ;-)

[filux]

A lot of developers for this purpose have second "frozen branch", and commiting to it only backwards compatible patches and per some (short) time they doing based on this branch the next stable version e.g. X.X.0 > X.X.1,

That's what SMF and JQuery do. Both currently have a version 1.x and 2.x. The older versions only get bug fixes. However, I don't feel that's a good idea for MG: takes up too many resources and we want players to have the latest and greatest version.

This is bad comparison. JQuery has in parallel in development 2 completely different and incompatible stable releases (since few years?).
If Megaglest could develop and support simultaneously v.2.X.X and v.3.X.X then it could fit to this example.

>   Much better example (but surely still not perfect) is e.g. debian "Wheezy" 7.0 and 7.1 and now we have 7.2 as "frozen stable branch" (like MegaGlest stable)

>   ...and in parallel branch "Sid" (like MegaGlest dev - r.XXXX). 

>   Both branches meet in only at the short moment when the next stable version is released Jessie/8.0.

[titi]

ok lets stop the version discusion in this thread for now.

More installer testing:
Linux 64bit:
... all works, no problems found.

Windows installer:
- When you install in the end you get a question if you want to start megaglest now. If you say "yes" MG crashes. Looking at the errors, I think its because the working directory is not changed to the installation directory before megaglest.exe is launched. Either remove this direct launch or fix it.

- The map editor launches and you can edit the map, but when you try to leave it it hangs  :-/ . You have to  kill the program.

- When I tried the whole installation process again and I said "no" to launch directly. When I did so , the installer was ended and left a file in C:\ called something like installerscreen.jpg ( I forgot the exact name after I removed it )

[Linux32 bit:]
Beside the size problem I talked about above there were no direct problems.
But a small problem I had was the following and maybe there is an idea how to fix it in future versions: 
I have a 64bit system and installed the 32bit installers, I was missing the wxwidget libs for 32 bit. When I launched the map editor via menu I got no error message, it just did not work.  Maybe in future we find a way to launch a terminal or anything to show the error.

UPDATE: This was related to pre release testing of installers !

[GunChleoc]

Congratulations on the release

[atze]

Congratulations on the release. Big thanks to the amazing community.