Officially supported Oolite version
Moderators: winston, another_commander
Officially supported Oolite version
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.
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
- ---- E L I T E ----
- Posts: 934
- Joined: Tue Dec 16, 2008 2:52 pm
- Location: Deep Horizon Industries Manufacturing & Research Site somewhere in G8...
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.
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.
Find my OXP's at:
Deep Horizon Industries - Your Planet Our Design
Deep Horizon Industries - Your Planet Our Design
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.maik wrote:Until they are marked as deprecated and eventually break or disappear.Cmd. Cheyd wrote: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.
My OXPs via Boxspace or from my Wiki pages .
Thargoid TV
Dropbox Referral Link
Thargoid TV
Dropbox Referral Link
I'm not convinced by that definition. I found on the web:Cmd. Cheyd wrote: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.
"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
- ---- E L I T E ----
- Posts: 934
- Joined: Tue Dec 16, 2008 2:52 pm
- Location: Deep Horizon Industries Manufacturing & Research Site somewhere in G8...
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.
Find my OXP's at:
Deep Horizon Industries - Your Planet Our Design
Deep Horizon Industries - Your Planet Our Design
- Commander McLane
- ---- E L I T E ----
- Posts: 9520
- Joined: Thu Dec 14, 2006 9:08 am
- Location: a Hacker Outpost in a moderately remote area
- Contact:
Re: Officially supported Oolite version
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.mcarans wrote: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?
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.
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.
Hey, free OXPs: farsun v1.05 & tty v0.5! :0)
- maik
- Wiki Wizard
- Posts: 2026
- Joined: Wed Mar 10, 2010 12:30 pm
- Location: Ljubljana, Slovenia (mainly industrial, feudal, TL12)
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).Kaks wrote: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.
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?
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.maik wrote: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?
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.
My OXPs via Boxspace or from my Wiki pages .
Thargoid TV
Dropbox Referral Link
Thargoid TV
Dropbox Referral Link
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.Cmd. Cheyd wrote: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.
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"?Commander McLane wrote: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.mcarans wrote: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?
-
- Quite Grand Sub-Admiral
- Posts: 6645
- Joined: Wed Feb 28, 2007 7:54 am
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."
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."