Mogre 1.7.2 or Mogre 1.8 ?

I was wondering what our users think should be the next release of Mogre. Do you think a Mogre version updated to support Ogre 1.7.2 should be released soon? Or would you prefer if we focus on getting everything prepared for a Mogre version that is compatible with 1.8, so that we can switch to 1.8 quickly after the release?

My vote would go to 1.8 as I like to stay current.

I think it would be good to update Mogre 1.7.
It's good to have a stable Mogre 1.7 release, which contains the latest version Ogre 1.7 version.
The changes shouldn't be as much difficult as for Mogre 1.8.

We also should keep the add-ons in mind.
Many users needs at least one of them. Updating the add-ons can be difficult.
With Mogre 1.7 many of them do work. So it's a good base for Mogre users.

It's good to have a focus to Mogre 1.8, but we shouldn't skip the update to 1.7.2.
You (mstoyke) wrote that Ogre 1.8 changed to CMake, which cause much trouble for us and need much work for updating the Mogre wrapper. So it's one more reason to do the smaller task at first (1.7.2).

I'm sure that some people will call for a quick release of Mogre 1.8.
But I suppose you need much time for the wrapper modification (or for the Ogre code modification in the pre-build step?).
So it's better to have a stable 1.7.2 than waiting a longer time for the Mogre 1.8 release.
Additionally the 1.8 version could have hard bugs and 1.7.2 would be more stable.

This is my personal opinion. Maybe other people think different.

For my project I stick with Mogre 1.6. It works well. (Just for interest I tried an update to Mogre 1.7, but this failed, because a needed add-on causes much trouble.)

This is my personal opinion. Maybe other people think different.
This is a "cast your vote" thread - it's all personal opinion

I'm in the "probably more stable & more compatible" 1.7.2 camp

I'm in the "probably more stable & more compatible" 1.7.2 camp

Me too.
But in my naive world, wrapping 1.7.2 should be very simmilar to 1.7.1 and shouldn't delay 1.8 for too long. What about addons? Do they have to be rewrapped between 1.7.1 and 1.7.2 if the interfaces stay the same?

I'm in the "probably more stable & more compatible" 1.7.2 camp

Me too.
But in my naive world, wrapping 1.7.2 should be very simmilar to 1.7.1 and shouldn't delay 1.8 for too long. What about addons? Do they have to be rewrapped between 1.7.1 and 1.7.2 if the interfaces stay the same?
That would depend on each individual addon. Which in turn would probably go hand-in-hand with whether or not the native addon has to be modified for 1.8.

tafkag, welcome to Mogre and thanks for your feedback.

Please look also to a second forum topic and give your priority vote for further Mogre development:
viewtopic.php?f=8&t=13225

So for example we know which add-ons are important for you.

I'm currently refractoring and documenting the whole AutoWrap code (which is quite hard as there's virtually no documentation at all in the code nor elsewhere). Perhaps this then could be used as starting point for creating a PInvoke wrapper but there's still a long way to go. You can check on the progress here:

http://bitbucket.org/manski/mymogre/ (branch: autowrap-dev)
(Post from here)

The wrapper documentation is a little bit hidden. Here are the direct links:
http://bitbucket.org/manski/mymogre/src/tip/build.txt (main doku)
http://bitbucket.org/manski/mymogre/src/tip/Codegen/AutoWrap/readme.txt (main doku)
http://bitbucket.org/manski/mymogre/src/tip/Codegen/cpp2java/readme.txt (tiny notes)
http://bitbucket.org/manski/mymogre/src/tip/Codegen/mogre_xml/readme.txt (tiny notes)


I will soon take some time to review the code changes that manski made. Then I will merge them into the official repository and I think manski might very soon have write access to the repository

I'm not sure whether you really want to review all code changes (as there are many) As for the code changes: I'm trying to be very careful about all code changes. Therefore before I commit a change, I always regenerate the whole MOGRE source code and compare it with the previous version. This way I can ensure that I don't introduce bugs/code that changes the code generation in some unwanted way. (This make the code rewrite much easier btw as the MOGRE code is my test suite.) However, it's still possible that I introduce bugs (by mistake, of course) in methods that aren't currently used for MOGRE's code generation. In this case (as in all others) any feedback is appreciated.

Regarding merging the code into the official repository: There are some changes that you should be aware of:

1. I've slightly changed the UI so screenshots and tutorials need to be updated.[/*:m]
   
2. I've reformatted some files of AutoWrap's code with my own styleguide. So some files are still in Bekas' style and some in mine. Sorry about that but Visual Studio is simply a horrible IDE (in some places) and doesn't allow me to specify a code style on a per-project- or per-solution-basis.[/*:m]
   
3. Currently the generated code will use two spaces instead of one tab for indention (I'm not a big fan of tabs as everyone has different tab widths) and use Windows line endings (instead of Linux line endings), though this is configurable.[/*:m]
   
4. The biggest changes (so far) is that my AutoWrap implementation creates set accessors for boolean property (where the old implementation create set methods). You can find the change to the code in changeset f24fcc3ed3fc. This is change is important as it breaks backward compatibility. I did this code change, as IMHO the code now does the correct thing.[/*:m][/list:u]
   
   I just need to make sure first that his changes will not break the code changes that were necessary for the new components.
   

Did a Mogre maintainer includes the improvements of manski to the official repository?
If not, please check the changes and think about to do it.