http://ofbiz.116.s1.nabble.com/release4-0-OFBIZ-1106-in-or-out-tp185421p185456.html
faster. The committers have put a lot more time into contributing to the
that is the reverse of how it should be. No matter what the release plan
>
> about a month ago david ask the community for feed back on those that
> have 4.0 in production.
> I have not see that much feed back about it so apparently there are not
> that many using it in production.
> I believe once more report that they are using 4.0 in production and are
> not running into problems that would the be point to freeze it and
> release.
>
>
>
> Jonathon -- Improov sent the following on 11/16/2007 7:18 PM:
> > Well, clearchris has a point. Is there a defined release date for 4.0?
> >
> > It depends on the management's view of OFBiz 4.0. If it is considered
> > alpha, go on ahead and insert any amount of enhancements into it. But if
> > it is considered beta, it would be good to be strict about things, and
> > pop in only bug fixes.
> >
> > The question to ask is whether management intends for OFBiz 4.0 to be
> > frozen or not. Is it released/published already or not? If it is
> > considered already published, I'd really like to see further
> > enhancements in OFBiz 4.1. From a psychological perspective, it's
> > exciting to see OFBiz 4.1, rather than see OFBiz 4.0 improve
> > tremendously "behind-the-scenes" over one long year.
> >
> > Picture what I'd tell my clients: "Boss, I know OFBiz 4.0 was shaky 10
> > months ago, but the 4.0 then is a far cry from the 4.0 now!". It'd be
> > easier saying: "Boss, we now have OFBiz 4.4. Here are the list of
> > improvements over 4.0.".
> >
> > Then some folks may say that OFBiz 4.0 as it is now is unusable, that no
> > one in right mind will use 4.0 given the horrible security issue
> > outstanding. What then? I say, we let 4.0 die. Time to move on! 4.0 was
> > published, management should stick to that decision. Roll out the next
> > version!
> >
> > Now on to technical considerations. SVN branches are "hotlinked", ie
> > branching 4.1 from 4.0 only creates a cheap reference to 4.0, not an
> > entire copy of 4.0. Any changes to 4.1 will then take up further
> > harddisk space, so only deltas above 4.0 are stored on disk. There will
> > still be only *one* copy of the entire 4.0 code.
> >
> > Now we question whether there'll be tons of confusion if we roll out a
> > whole army of the 4.x family. The crucial thing we *must* do is to make
> > sure the 4.x family are fully compatible with one another such that
> > upgrading/downgrading along the family line requires zero migration
> > effort. Also, make sure that any bug fixes can be *uniformly* applied
> > across the whole family. What that also means is any enhancements that
> > are too radical and that may break above requirement cannot be put into
> > the 4.x family.
> >
> > So what's the point of having 4.0 and 4.1? Ease of bug-reporting! A
> > non-techie person can say "I found the bug in 4.0". So he didn't have
> > time to upgrade to 4.1, or maybe 4.1 is an unlucky number for him. Then
> > the response we give him? "Sir, have you gotten the latest updates for
> > 4.0"? He either says "no" and he updates and retest, or he says "yes"
> > and we hunt for the bug in that *specific release version that is 4.0*!
> > Or if we want to, we could say that "4.0 is dead, please use 4.2".
> >
> > In short, here's the plan. OFBiz 4.1 goes into alpha, and takes in all
> > sorts of enhancements as long as they don't break backward-compatibility
> > with 4.0. OFBiz 4.0 continues beta, until such time that it is
> > super-bugfree. We'll have a series of 4.x members, with the earlier ones
> > getting more stable than the later ones (later ones take in risky new
> > enhancements). How will that happen? Anyone finding a bug in the latest
> > 4.x member can also apply the similar bug fix to 4.0 (or 4.y where y <
> > x). The bug fixes cascade down to earlier 4.x members, making them more
> > stable over time, even as the community tests only the newest 4.xmember.
> >
> > Throughout the whole 4.x lineage, no extra harddisk space is taken up.
> > SVN makes cheap "copies". Only deltas are stored.
> >
> > Is that clearly explained? Or did I just confuse version control with
> > cake-baking?
> >
> > Jonathon
> >
> > Jacques Le Roux wrote:
> >> Finally, have we an idea about what to do :o)
> >>
> >> Do we need a vote for this ? Maybe a generalisation for "security"
> >> case as features to back port in any case ?
> >> Create release4.0 (and later when they will come) branches as proposed
> >> by Jonathon ?
> >>
> >> Jacques
> >>
> >> De : "clearchris" <
[hidden email]>
> >>> I had no idea the can of worms this would open up when I entered the
> >>> issue.
> >>>
> >>> I come down on the side of wanting this patch in the release branch.
> >>>
> >>> Further, as there is no defined release date for 4.0, I would
> >>> consider it
> >>> still open for very high-priority issues that are not traditionally
> >>> defined
> >>> as "bugs". Ofbiz customers, if they are using the release branch in
> >>> production or close to production would probably do well to lag a bit
> >>> and
> >>> run with an older revision of the release branch. Regressions can
> >>> always be
> >>> an issue, even with bug "fixes".
> >>>
> >>> Chris
> >>>
> >>> -----Original Message-----
> >>> From: David E Jones [mailto:
[hidden email]] Sent: Thursday,
> >>> November 15, 2007 4:11 PM
> >>> To:
[hidden email]
> >>> Subject: Re: release4.0: OFBIZ-1106 (in or out?)
> >>>
> >>>
> >>> On Nov 15, 2007, at 11:18 AM, Michael Jensen wrote:
> >>>
> >>>> Using that logic, you could say that almost any previous bugs were
> >>>> really "as-implemented" features and no changes should ever be made
> to
> >>>> the current release branch.
> >>>> If it was found somewhere in ofbiz that sensitive information was
> >>>> submitted over http instead of https, would that be considered a bug?
> >>>> Or would it be discounted as "well, it's a bad choice but that's
> >>>> how it
> >>>> was implemented"?
> >>>>
> >>>> I understand that the difficult thing about this is that the bug/
> >>>> feature
> >>>> line has to be drawn somewhere. (I know where I'd draw it,
> especially
> >>>> on security related issues.)
> >>> It's really not that tough... As I described in depth in my previous
> >>> post in this thread there is no need to muddy the meaning of "bug".
> >>>
> >>> Maybe the word you are looking for is "issue"?
> >>>
> >>> This isn't a "bug" per-se, but certainly an "issue" and solving that
> >>> issue requires a new feature. That doesn't mean it can't go into the
> >>> release branch, but non-bug-fixes should be carefully considered
> >>> before being added.
> >>>
> >>>> I'm curious to see how things pan out on this. It will tell me how
> >>>> seriously security is taken by the people driving ofbiz.
> >>> This is a common misconception. There are no "people driving ofbiz".
> >>>
> >>> OFBiz is a community-driven project and things happen when a user
> >>> needs something, implements it, and contributes it back to the
> >>> project. Even committers on OFBiz are just users who have a long
> >>> history of contributions and are invited to be committers to
> >>> facilitate further involvement.
> >>>
> >>> Security or not, things will only be fixed if someone cares enough.
> >>> The flip side of that is that if someone doesn't like how something
> >>> is in OFBiz and they don't do anything about it, they have only
> >>> themselves to blame, as uncomfortable and frighteningly empowering
> >>> as that may be. ;)
> >>>
> >>> -David
> >>>
> >>>
> >>>> Ray Barlow wrote:
> >>>>> As you say plenty of good points so rather than repeat lengthy
> >>>>> arguments
> >>>>> for or against I'll keep it simple and just say I don't think it
> >>>>> should
> >>>>> be described as a bug as it was implemented this way. Bad choice
> >>>>> maybe
> >>>>> but it's a feature change.
> >>>>>
> >>>>> Having said that I do think it should be seriously considered for
> the
> >>>>> release branch because of it's small footprint and improvement on
> >>>>> a very
> >>>>> weak and insecure area.
> >>>>>
> >>>>> Ray
> >>>>>
> >>>>>
> >>>>> Dan Shields wrote:
> >>>>>> Thanks Jacques. Is there any further action by me that might be
> >>>>>> advised? I was wondering because I was considering declaring a
> >>>>>> referendum on the issue on the user list as per David Jones'
> >>>>>> suggestion.
> >>>>>>
> >>>>>> Wow I guess that what we have here is "the absence of this new
> >>>>>> feature
> >>>>>> is a bug".
> >>>>>>
> >>>>>> I must say, the dev-debate that it has inspired has been
> impressive!
> >>>>>> There are good arguments both for viewing the patch as a bug, as
> >>>>>> well
> >>>>>> as equally good arguments for viewing it as a feature. It really
> >>>>>> surprised me because up until that point in time (when I blindly
> >>>>>> stumbled into this) my view was entirely to think about it as a bug
> >>>>>> only. The author of OFBIZ-1106 never knew the difference between
> >>>>>> 'code that failed to hide the password' and 'the complete absence
> of
> >>>>>> code that successfully hid the password', he just knew that the
> >>>>>> software did not do 'as it should', and this was exactly my point
> of
> >>>>>> view in devising a solution as well. It requires a strong
> >>>>>> metaphysical argument to even tell the difference between the
> points
> >>>>>> of fact that might exist in the software that would reveal the
> >>>>>> actual
> >>>>>> intent of the original design. My feeling is that it was either
> >>>>>> overlooked accidentally, or it was not convenient to declare the
> XUI
> >>>>>> XPage in a manner that made sense to have both regular input and
> >>>>>> password input in the same node of the tree but at different times
> >>>>>> (this convenience is what I provided in the patch).
> >>>>>>
> >>>>>> As I said above I am willing to take this to the user list and
> >>>>>> invite
> >>>>>> all users who run a release4.0 branch to submit an accept/reject
> >>>>>> vote,
> >>>>>> as I think this feature/bug (or bug/feature) is important enough to
> >>>>>> the success of release4.0 to warrant.
> >>>>>>
> >>>>>> I am happily sitting on the fence and content to let this issue go
> >>>>>> either way. I am finding it fascinating.
> >>>>>>
> >>>>>> Cheers all
> >>>>>> Dan
> >>>>>>
> >>>>>>
> >>>
> >>
> >>
> >
> >
> >
> >
>