Current state of Mac version?

[phkb]

In Oolite’s case, since v1.80, odd numbers have been the nightly version, even numbers are of official release.

[another_commander]

Actually, for disambiguation, many projects assign different version number patterns to the nightlies. Meaning a nightly should never carry a 1.91 but a timestamp as version number.

For further disambiguation, the pattern we use for our nightlies is MajorVersion.MinorVersion.PatchVersion.SequentialCommitNumber-BuildTimeStampInyymmddFormat-gitCommitHash. The game's log header for nightlies starts by stating this information as per this example:

Code: Select all

Opening log for Oolite development version 1.91.0.7303-210819-84006e2 (x86-64 test release) under Windows 10.0.19042.1288  64-bit at 2021-11-12 08:50:00 +0200.

This version information is also displayed continuously during the game as a watermark on the top right corner of the screen.

Odd version numbers (e.g. 1.91) indicate that this is a development version. When the game is ready for a new release, it is declared stable by switching its version number to even.

[hiran]

Actually, for disambiguation, many projects assign different version number patterns to the nightlies. Meaning a nightly should never carry a 1.91 but a timestamp as version number.

For further disambiguation, the pattern we use for our nightlies is MajorVersion.MinorVersion.PatchVersion.SequentialCommitNumber-BuildTimeStampInyymmddFormat-gitCommitHash. The game's log header for nightlies starts by stating this information as per this example:

Code: Select all

Opening log for Oolite development version 1.91.0.7303-210819-84006e2 (x86-64 test release) under Windows 10.0.19042.1288  64-bit at 2021-11-12 08:50:00 +0200.

This version information is also displayed continuously during the game as a watermark on the top right corner of the screen.

Odd version numbers (e.g. 1.91) indicate that this is a development version. When the game is ready for a new release, it is declared stable by switching its version number to even.

That's even better than I expected. Thank you for the clarification.

[Cody]

That's even better than I expected.

It's not all pink gins and long lunches at the Admiralty, you know!

[Cholmondely]

Actually, for disambiguation, many projects assign different version number patterns to the nightlies. Meaning a nightly should never carry a 1.91 but a timestamp as version number.

In Oolite’s case, since v1.80, odd numbers have been the nightly version, even numbers are of official release.

Just to say, complete ignoramus that I am, I understood the current Oolite version numbering system right from the beginning. It is nice and simple (especially for non-programmers) - and makes rather more sense than the previous mess with stable (v.1.60, 1.76, 1.761, 1.77 & 1.771) and non-stable versions (all the others). Although I can see how the previous mess came about. I also understood that eg. the current v1.91 goes through diverse incarnations too.

And, just to be my usual nit-picking pedantic editorial self, I understand that the new process started with v.1.79!

As a matter of interest, was this numeration all cim's idea? Or somebody else's?

Hiran - I totally understand why you prefer the datestamp. Especially after looking at what you have been through with tweaking your Oolite Communicator (5 versions so far? More?). But I do find the Oolite numbering system so much more intuitive, personally speaking.

So, just to be sure, am I given to understand that the only Mac versions are the "debug" and the "main", and that there are no longer AppleMac nightlies being written?

Oh - and what is a "trunk" version? I've seen that term here and there on this BB...

And - I presume that Giles and Ahruman did not know in advance which versions would be stable, whereas now our developers do. Is the reason for this change in knowledge comprehensible by such as myself?

[Cody]

... there are no longer AppleMac nightlies being written?

As it stands, there are no nightlies being written for any OS.

[another_commander]

As a matter of interest, was this numeration all cim's idea? Or somebody else's?

It was Jens'.

Oh - and what is a "trunk" version? I've seen that term here and there on this BB...

A trunk version is a build of the game corresponding to the latest source code commit on the project's master branch on github. You can alternatively say it is "the nightly of the latest and greatest code currently in the repository".

[hiran]

Hiran - I totally understand why you prefer the datestamp. Especially after looking at what you have been through with tweaking your Oolite Communicator (5 versions so far? More?). But I do find the Oolite numbering system so much more intuitive, personally speaking.

Well, sometimes you do not know whether the new build actually qualifies as release. So you treat it as development build, and as I was corrected there is a lot of information in an Oolite nightly build name. Once tested and found stable, the same code can then be distributed with another name - and you have a version number that users can relate to.
The same would happen with the stuff I create, except that we never left the 'proof of concept' phase.

Oh - and what is a "trunk" version? I've seen that term here and there on this BB...

When several developers work on features in parallel, it is very useful to develop each of them in an isolated environment to not mess with side effects. Just imagine you try out a new rendering model on one specific coriolis station, while another developer changes the universe and the tests happen in another galaxy. So every feature is developed on it's own branch and need to get merged when the work is considered 'done', and the main branch is called trunk where everything gets merged into.
So each branch can be compiled into a more or less working product, and the trunk can also be compiled into a more or less working product. With so many different versions flying around it is important you can relate to a specific one if need be.

And - I presume that Giles and Ahruman did not know in advance which versions would be stable, whereas now our developers do. Is the reason for this change in knowledge comprehensible by such as myself?

Also today you do not know. So you release something attached with a sticker 'unstable', test it out until you are satisfied and then label it 'stable'.
The details in the process may look slightly different but the basic principle remains.

[hiran]

That's even better than I expected.

It's not all pink gins and long lunches at the Admiralty, you know!

Full ack! The stable running Oolite version is pretty good proof of that!

[Cody]

The stable running Oolite version is pretty good proof of that!

As is trunk. I've been running the nightlies (playing my normal game) for eight years now, and they've yet to break my machine!

[hiran]

The stable running Oolite version is pretty good proof of that!

As is trunk. I've been running the nightlies (playing my normal game) for eight years now, and they've yet to break my machine!

I am trying to get Oolite builds for Mac running. I have no Mac, never had one and definitely never build any Objective C project, not to talk about Oolite.

The most current Github master branch produced lots of warnings which i removed, then it was missing libpng and now I get some errors like this:

Code: Select all

error: meaningless 'volatile' on asm outside function

I'm afraid my wisdom is not sufficient to decide how to get around this. Should I change the compiler? Should I change the code?
Any help appreciated.

[another_commander]

You may want to have a look at this: https://github.com/OoliteProject/oolite/pull/318
and maybe this too: https://github.com/OoliteProject/oolite ... 44e151f685

This is what Jens had to change in order to make Oolite build with a newer Xcode. Unfortunately his PR had to be declined because accepting it back then meant that we would have stopped being able to create releases for the Mac.

The asm error you are getting is quite exotic, I must say. Haven't googled it (and don't have time for that either), but I seem to recall that newer Macs run on ARM processors, am I right? Maybe this is a conflict with asm written for older Intel processors? Really don't know and could be way off the mark, but at least I hope these few hints can be somewhat helpful.

[Cholmondely]

The stable running Oolite version is pretty good proof of that!

As is trunk. I've been running the nightlies (playing my normal game) for eight years now, and they've yet to break my machine!

I am trying to get Oolite builds for Mac running. I have no Mac, never had one and definitely never build any Objective C project, not to talk about Oolite.

The most current Github master branch produced lots of warnings which i removed, then it was missing libpng and now I get some errors like this:

Code: Select all

error: meaningless 'volatile' on asm outside function

I'm afraid my wisdom is not sufficient to decide how to get around this. Should I change the compiler? Should I change the code?
Any help appreciated.

Do let me know if I can help in any way...

[hiran]

You may want to have a look at this: https://github.com/OoliteProject/oolite/pull/318
and maybe this too: https://github.com/OoliteProject/oolite ... 44e151f685

This is what Jens had to change in order to make Oolite build with a newer Xcode. Unfortunately his PR had to be declined because accepting it back then meant that we would have stopped being able to create releases for the Mac.

The asm error you are getting is quite exotic, I must say. Haven't googled it (and don't have time for that either), but I seem to recall that newer Macs run on ARM processors, am I right? Maybe this is a conflict with asm written for older Intel processors? Really don't know and could be way off the mark, but at least I hope these few hints can be somewhat helpful.

I shall take a look. That one is not too easy to digest, and I think I hit something that Jens could not foresee at that time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89585
Just look when Jens created his pull request and when gcc 8.3 was released and the bug reported.

A backport of some gcc 9.0 breaking change also broke gcc 8.3. This is where we may decide to
- either change/upgrade the source
- or fallback to gcc 8.2

[Commander_X]

[...]

Code: Select all

error: meaningless 'volatile' on asm outside function

[...]

In my build attempt ("visual" Xcode), the environment suggested to get rid of the 'volatile' keyword, which, after performing (I think there were 3 occurrences) continued the compilation.
Again, the resulting application, didn't run, unfortunately.