Formal specification of what is allowed in versions Topic is solved

What it says on the tin: a place to discuss proposed new features.
Post Reply
balloyd1
Gnoblar
Posts: 16
Joined: Mon Sep 05, 2005 7:06 pm
x 1

Formal specification of what is allowed in versions

Post by balloyd1 »

I have had several surprises recently where pulling a point release brings breaking API changes. IE, 1.10.2 to 1.10.3 requires code changes to compile my apps against it, not just to use the new features. A specification of which branches are considered development and open for any change and which are more maintenance oriented, thus API stable would help when users are selecting branches. A specification of what kinds and amount of changes that can be expected when moving between revisions would also help. Also, an up to date listing of the differences between branches and current state would also help. I realize 2.1 is under heavy development, but there was a time 2.0 was considered good for new development work but it still doesn't appear to have working samples or documentation so people can.

From outside viewing in, I cannot really see any differences in version numbers. Documentation could help this.
paroj
OGRE Team Member
OGRE Team Member
Posts: 1993
Joined: Sun Mar 30, 2014 2:51 pm
x 1073
Contact:

Re: Formal specification of what is allowed in versions

Post by paroj »

note that there has not been an formal announcement for the 1.10 release yet. While you righteously assume 1.10.3 to be a point release it has the nature of a release candidate. This is unfortunate, but stems from the fact that 1.10.0 was released as the github fork and I wanted to avoid two different 1.10.0 releases out there. 1.10.4 is what is going to be finally frozen API wise and announced on the front page.
Nevertheless please report any API breakage as an regression either on JIRA or on github.

Generally we are commited to keep the API stable across the minor version (1.10.x) - except the Component is marked BETA, which means that we know of some API deficiencies, but the code is generally stable enough to be used. For Plugins and RenderSystems only the abstract API specified in OgreMain is frozen.

Changes that are deliberatly allowed between patch releases are deprecations and behavioral changes (like new exceptions or, indeed, bugfixes). For a changelog of 1.10 so far see: https://github.com/OGRECave/ogre/releases

We do not provide any ABI stability at this point as the codebase does not allow us to do so.

Regarding 2.0: it never really passed RC1 status and thus only is recommended as a stepping stone for porting from 1.9 to 2.1 (or to get rid of the CPU bottleneck in 1.9). This is reflected on the "What version to choose" since a few days.
Post Reply