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.x member. > > 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" <[EMAIL PROTECTED]> >>> 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:[EMAIL PROTECTED] Sent: Thursday, >>> November 15, 2007 4:11 PM >>> To: dev@ofbiz.apache.org >>> 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 >>>>>> >>>>>> >>> >> >> > > > >
