Officially supported Oolite version

[mcarans]

Hypothetically, if I found a serious bug that affected 1.65 and 1.74.2, would the bug be fixed in 1.65.x, 1.74.x or both?

The website says:
Version 1.65, released in June 2006, is the latest full release of Oolite. However, the test releases are faster, prettier, more stable and use less memory, so ignoring the full release and using the test releases instead is recommended. Yes, we realise this sounds silly.

Assuming the answer to my question is that noone will bug fix 1.65, why continue to refer to it as the "latest full release of Oolite" or the "stable" release? Unsupported latest full release sounds....well silly as the website says.

[Cmd. Cheyd]

Because Stable in software development is not a reference to how many bugs it has, how often it crashes, or anything like that. It's a reference to the API's / interfaces. A 'stable' release means that any feature that appears in that version will appear in all future versions. The way you access / leverage that feature will remain consistent in all future versions.

This is why we OXP authors have to recode our stuff every release. We're developing against / for the "Test" releases that are not stable. If we were developing against / for the "Stable" release, our OXP's would work on every version of Oolite until they scrap the code-base entirely.

[maik]

A 'stable' release means that any feature that appears in that version will appear in all future versions. The way you access / leverage that feature will remain consistent in all future versions.

Until they are marked as deprecated and eventually break or disappear.

[Thargoid]

A 'stable' release means that any feature that appears in that version will appear in all future versions. The way you access / leverage that feature will remain consistent in all future versions.

Until they are marked as deprecated and eventually break or disappear.

No, if they are in a stable release then they should appear in all future versions. There would be no depreciation, that is something for the test releases as the good Commander already said.

[mcarans]

Because Stable in software development is not a reference to how many bugs it has, how often it crashes, or anything like that. It's a reference to the API's / interfaces. A 'stable' release means that any feature that appears in that version will appear in all future versions. The way you access / leverage that feature will remain consistent in all future versions.

This is why we OXP authors have to recode our stuff every release. We're developing against / for the "Test" releases that are not stable. If we were developing against / for the "Stable" release, our OXP's would work on every version of Oolite until they scrap the code-base entirely.

I'm not convinced by that definition. I found on the web:
"The stable distribution of Debian is the latest version which was released for wide use. This means it was tested for a long time before enough problems were corrected to obtain what the Debian release process deems a stable operating system.

Debian releases stable when the release team is confident that fewer peculiar problems will occur with a new release than with the former one. "

[Cmd. Cheyd]

Very well. Then I shall refrain from answering your questions in the future as you do not seem to wish to accept them. I am always one to encourage someone to educate themselves, so I shall cease to do so for you.

[Commander McLane]

Hypothetically, if I found a serious bug that affected 1.65 and 1.74.2, would the bug be fixed in 1.65.x, 1.74.x or both?

Obviously there is no (and will be no) 1.65.x. Bug fixes for 1.65 were made in 1.67, and then again in 1.68, and in 1.69, and in 1.70, and in 1.71, and in 1.72, and in 1.73, and in 1.74. In other words: 1.74.2 is itself the bugfix of 1.65. Why should you want another one? If you find something that was broken in 1.65 and is still broken in 1.74.2, you should report it in the proper way, as explained in the Bug Report Guidelines, which are a sticky in this very forum, so that it may get fixed for the next release.

[Kaks]

Yep, if you can replicate a 1.65 bug in 1.74.x, we'll fix trunk, as we're working towards the next stable release. No 1.65.x are either planned or likely.

As a general principle, the next stable release of Oolite will support all the features of 1.65, and all the new apis and features in the next stable will be supported for at least the stable release after that. With test versions, we have already removed/added to/tweaked quite a number of feature, sometimes deprecating & removing stuff from one test release to the next.

Different projects have different definitions for what stable is. Amazingly, the definition adopted by Oolite is somewhat stricter than the one adopted by Debian.

However, very few API changes/extensions are planned for 1.75, as we're approaching our target for stable.

[maik]

As a general principle, the next stable release of Oolite will support all the features of 1.65, and all the new apis and features in the next stable will be supported for at least the stable release after that.

In other words, you might mark API features of 1.65 (n) as deprecated in the next stable version (n+1) and stop supporting them in the following stable version (n+2).

I think the point that mcarans was getting at, namely mentioning Oolite 1.65 on the web page, actually needs to be considered from two perspectives:

Oolite players should always download the latest unstable version as all bugs will be fixed there. This can indeed be confusing (a version that is not called stable but has all the bug fixes). I know it's mentioned on the web page, but still... even here it took a few posts to explain what is meant by stable and it does not seem to cater to what mere players expect (and I venture the guess that they are the vast majority of people downloading Oolite).

Oolite OXP authors need to make a choice if they want to develop against a stable API (1.65) and have the guarantee that this will still work at least up to and including then next stable version, or if they want to embrace all the goodness in the latest unstable version but face problems when the API changes until there is a new stable version. So for them the distinction is very important.

So it all boils down to the main(!) target audience for the web page: if it's users then I suggest to only offer the latest version and not call it a test release and move the stable/unstable distinction to a separate page intended for developers. If it's OXP developers then it's good as it is.

Postscript: I wonder if the discussion is not entirely academic. Are there OXP authors who continue to target only 1.65 and wait until the next stable version is available before they make use of new (post-1.65) features?

[Thargoid]

Oolite OXP authors need to make a choice if they want to develop against a stable API (1.65) and have the guarantee that this will still work at least up to and including then next stable version, or if they want to embrace all the goodness in the latest unstable version but face problems when the API changes until there is a new stable version. So for them the distinction is very important.

So it all boils down to the main(!) target audience for the web page: if it's users then I suggest to only offer the latest version and not call it a test release and move the stable/unstable distinction to a separate page intended for developers. If it's OXP developers then it's good as it is.

Postscript: I wonder if the discussion is not entirely academic. Are there OXP authors who continue to target only 1.65 and wait until the next stable version is available before they make use of new (post-1.65) features?

It's no choice, as 1.65 was lacking things like Javascript and shader support, plus had a lot more limitations like polygon count and legacy scripting.

Hence for almost every OXP that has been written post-1.65 they are built against the test release of the time rather than the stable 1.65. There are a few which are still backward compatible to 1.65, but they are fairly few and far between.

Yes having to revise the OXPs for test release version-ups is sometimes a pain, but it's a fair trade-off for all the new features, functions and possibilities that such revisions also bring (often at our request to make the OXPs better or easier).

So yes, your discussion is fairly academic at least from this OXP makers viewpoint.

[mcarans]

Very well. Then I shall refrain from answering your questions in the future as you do not seem to wish to accept them. I am always one to encourage someone to educate themselves, so I shall cease to do so for you.

Cmd. Cheyd I wasn't trying to rubbish your post. I just thought about its implications and realised that it did not seem to make sense so investigated some more to see if I could corroborate your post on the web. In the process of my search for information, I found the description for Debian which I posted.

Hypothetically, if I found a serious bug that affected 1.65 and 1.74.2, would the bug be fixed in 1.65.x, 1.74.x or both?

Obviously there is no (and will be no) 1.65.x. Bug fixes for 1.65 were made in 1.67, and then again in 1.68, and in 1.69, and in 1.70, and in 1.71, and in 1.72, and in 1.73, and in 1.74. In other words: 1.74.2 is itself the bugfix of 1.65. Why should you want another one? If you find something that was broken in 1.65 and is still broken in 1.74.2, you should report it in the proper way, as explained in the Bug Report Guidelines, which are a sticky in this very forum, so that it may get fixed for the next release.

If 1.74.2 is a bugfix of 1.65, then shouldn't 1.74.2 be the stable version or "latest full release of Oolite"?

[maik]

If 1.74.2 is a bugfix of 1.65, then shouldn't 1.74.2 be the stable version or "latest full release of Oolite"?

From a user point of view: yes. From an OXP author point of view: no. "Stable" means different things to those two.

[another_commander]

Not a bug report. Moved to Discussion.

[Switeck]

From a user point of view: yes. From an OXP author point of view: no. "Stable" means different things to those two.

I doubt most OXP writers are making OXPs with v1.65 compatibility in mind at this point.

[mcarans]

What I was trying to drive at is wouldn't it be better to just remove references to the stable version 1.65? It seems to serve little purpose.

Instead we could refer to a "supported" Oolite version which might be 1.74 or maybe 1.74.2. I'm not trying to tread on anyone's toes here - it's just that it seems better to change nomenclature than put on the web "...using the test releases instead is recommended. Yes, we realise this sounds silly."