Irrlicht Engine

Hallo

Being relatively new to the Irrlicht engine, albeit not withstanding the addition of a large number of grey hairs, can I ask some questions about the development process of the library.

The current release is 1.4 and it appears that there is constant development (via the tracker) of the next (1.5?) version of the library. Who decides when this will be released?
Who decides what will be released?
What influence do we as 'users' have over the direction of the development?

Maybe these questions are answered elsewhere - please direct us 'noobs' to such a resource. I think it will be helpful to anybody that wants to make use of this fantastic library in a 'serious' application, as 'our' release schedules might need to be adjusted to the up and coming release of the library.

Anton

aheymann wrote:Who decides when this will be released?

The active devs with SVN access, i.e. hybrid, bitplane and luke. Perhaps Niko as well, especially if he wants to co-ordinate features with IrrEdit / IrrKlang.

aheymann wrote:Who decides what will be released?

See above.

aheymann wrote:What influence do we as 'users' have over the direction of the development?

Ask for features, or better yet, provide them. The best way to get a change incorporated is to package it in a way that minimises the effort required by a dev to understand and verify it, i.e.:

Provide a Subversion patch.
Provide a clear description of what the problem is, and how your patch solves it.
Provide a test case, or a fully compilable test app that clearly demonstrates the before and after behaviour.
If it's a small patch, it can go in the bug forum, and/or you can upload it to the Sourceforge patch tracker (see my sig) where it won't get forgotten about.

It can be hard to be patient when you've got a simple patch languishing in the tracker, but the devs will get around to it eventually. As I keep telling myself.

Your collision response animator issue is a great candidate for a patch. It's well defined and isolated, and should get you started on contributing.

rogerborg wrote:It can be hard to be patient when you've got a simple patch languishing in the tracker, but the devs will get around to it eventually. As I keep telling myself.

That's more hard then it sounds
After the first time I wasn't patient at all I've been fighting with myself not to annoy the developers with my future patches and it is not easy at all .

P.S
Just a reminder :
CFileSystem::addFolderFileArchive() bug fix

good question. If you can say one thing I prefer other examples, no new relasse, because first I have to learn this good

Thanks for the replies

I prefer to work with the current released version of a library, as (and I have been proved wrong many times before) it should be the most stable. However, features might be missing and/or not working properly, therefor a 'schedule' as to when releases can be expect would be very helpful. I have been in this business for many years, and yes I do not know how long a piece of string is, but some kind of indication as to expected release dates (and features) will be extremely helpful.

I have managed to implement in a few weeks an add-on to a CAD system, with quite complex user requirements, with really no serious problems (he says, as another 102 errors appear in the output window ).

Anton

If I remember correctly Niko decides when a release is made. I guess he consults the active developers and they suggest a release when they feel enough bugs and new features are ready, or something like that.

I've learned the hard way that fast releases are BAD so I stopped asking for it.

I can truly say that I 100% trust the devs to know when they should release a new version, whether it's vMajor.1 or v++Major.0 .

I'll just test the texture matrix changes in the 1.4 branch a little more and let the 1.4.1 release roll out soon. Don't know how long the preparation and final release will take, but it shouldn't take month anymore. The 1.5 release will take a little longer, though, because we still have many things to fix before it's ready. And it will also have a beta phase again (the 1.4.1 release shouldn't have too many problems, so it will be immediately released for real).
I don't know when we will have enough time for a proper schedule and planning. The general discussions, testing, patch support, forum and IRC talks, etc. already take a major part of my free time. And apparently also of the other dev team members. But it might become better sometimes

hybrid wrote:But it might become better sometimes

Maybe add another core developer like not long time ago ? (varmint )

P.S
It's very nice to hear the v1.4.1 is close.

P.P.S
It looks like every major release is followed by a vX.Y.1 version

Take your time - we're all glad about every bug that gets fixed before release :-)

But it would be nice if you could announce it 2-3 days before release, so the community can do a last check of the newest svn-version. That gives you some free testing... never a bad thing imho.

08.04.2008

hybrid wrote:I'll just test the texture matrix changes in the 1.4 branch a little more and let the 1.4.1 release roll out soon. Don't know how long the preparation and final release will take, but it shouldn't take month anymore. The 1.5 release will take a little longer, though, because we still have many things to fix before it's ready. And it will also have a beta phase again (the 1.4.1 release shouldn't have too many problems, so it will be immediately released for real).

he-he