On 8/3/06, Andrew Robinson <[EMAIL PROTECTED]> wrote:
MyFaces has been great in terms of growth and functionality, but it
suffers from constant instability (I am referring to core and
tomahawk). I don't think this is related to developers, code quality
or QA/testing near as much as the release management. The problem that
I keep observing is there is no stabilization of MyFaces:
* Each release is a combination of bug fixes and new features.
today I was already thinking, that we should keep the new feature size
much small and get the base more stable. Just an idea when walking home
from work
* Bugs are only fixed in future releases (even show stoppers)
* Releases are never patched/upgraded
for 1.1.4 we already patched the branch ...
but for the rest you are right
* New releases have a long turn around time from SNAPSHOT to release phase
lack of time / volunteers.
Although this system isn't that bad for testing and "playing around",
it is very detrimental to a commercial application or any released
right; some companies uses other impls for this reason.
(I am not talking about these "fast and small" pages apps,
dune with the last hype of technology... ;)
product built on MyFaces for that matter. I would like to propose the
following changes/adoption taken from the Linux kernel methodology:
* At least two active branches at all times
* New features are only introduced into odd number releases
* Bug fixes are always introduced on even number releases (unless they
are for a bug in an odd numbered branch)
* Minor releases on the active branches are done at frequent intervals
(at least 1 per month preferably)
Example:
1.1.2.x -- dead stable branch
1.1.3.x -- dead development branch
1.1.4.x -- current stable branch (* active)
1.1.5.x -- current development branch (* active)
Once an odd number branch is ready for promotion, all development on
it ceases. Two new branches are created. During this period, the bugs
continue to be applied to the previous stable branch, until a burn in
period is passed on the new stable branch which would have a beta or
release candidate naming. Example:
1.1.4.x -- current stable branch (* active -- mostly for mission
critical fixes only)
1.1.5.x -- dead development branch
1.1.6.RCx -- proposed stable branch built from 1.1.5.x features (* active)
1.1.7.x -- new development branch (* active)
The same would apply for 1.2.x branches.
This way users always have a proven release and know that it will be
more stable over time. Also, developers/contributors should be able to
submit patches on older stable releases and then new minor releases
can be released on older branches if called for.
Andrew, this makes all sense to me; the main problem is (to me) the
lack of time/manpower. I really would appreciate to stabilize the
current myfaces 1.1.x versions. But I think the more "buggy" part is
from the tomahawk side, than from MyFaces core. That's b/c there the
most "new" features go in.
The big reason I can for this is problems like:
http://issues.apache.org/jira/browse/MYFACES-1296
This bug was introduced in 1.1.2 and is not fixed in a release yet.
yes, that's really unhappy.
This bug has been a show stopper for three months now. The fix is in
1.1.4, but that branch is not released yet.
right, b/c another issue, has been introduced...
Thoughts?
Thanks for taking the time to read this through
thanks for taking the time to write it!!
.Matthias
-Andrew
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
