My strong preference would also be that we start applying major patches to branches.
Right now, it's somewhat of a task to find a version of MyFaces that has just the right amount of bugs :-) This actually hurts my ability to be a committer (and I am one!) because once I find a revision level that does everything I need, I'm hesitant to update again until I'm forced to do so. I suppose I could maintain a plain-text file somewhere of "good" revision numbers, but I'd rather be working on a branch with bug fixes. Some of these release issues we've been having wouldn't big as big a deal if we'd simply patch them up and do another minor release number. 1.1.3.1 would have likely been a fine release with only one bug fixed. On 8/4/06, Andrew Robinson <[EMAIL PROTECTED]> wrote:
As for time and volunteers, it is a deterrent to volunteers to help out because patches written for the current release are never used and you will never see that release fixed. I don't know if this is true for other people, but that is a large enough deterrent for me not to help out. People that help by submitting patches for bugs usually do so to fix the version they are using. If bug fix releases became available, perhaps more people would help out? (Also I admit that I am a Java 5 snob -- I greatly dislike coding on the dead 1.4 JDK) Thanks for your opinion. On 8/3/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > 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 >
