"Ronald" wrote : | Just like with a release cycle people can rely upon, the should be able to rely on what will be in that release. In many projects I worked on, knowing 6 weeks before a release that certain functionality that was scheduled to be in that release will not be in it is not something I can work with. | Agreed. The release cycle was introduced exactly for this, to make releases more predictable (as stated by Tom in the wiki) and thus to allow end-users to plan, too. "Ronald" wrote : | Looking at the past releases, each time issues were slipping to the next release, it did not happen often that there was a plethora of time. So I'd like to propose two things. | - Try to define (as good as possible, taking the above into account) plan at the beginning of e.g. release 4.3 the issues for 4.4, not plan them at the beginning (or half way as happened now) of 4.4 | - Take a little more time, so plan less 'issues' | Agreed. When you take a look at the great number of issues originally scheduled for a release it's alsmost clear that not all of them can be taken into account. But the decision which of them are needs to be made earlier (spoken from an enduser's point of view). This would help a lot. The second thing which comes to my mind are priorities. I think bug fixes and basic features should have priority over completely new features. New features are great but from my point of view they don't have a great value for real world use unless basic process engine things were taken care of, especially a complete history and a fully functional variable logging. Just my 2 cents. Have a nice day. :) Sebastian View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267732#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...