+1. The reason is simple: nobody takes the role of project manager in OFBiz.
When Redhat aquired JBoss, I found almost every project had a new project manager who really helped the projects released more and more predictable. At the beginning as TLP, Jacopo Cappellato looked like preparing the release version. And when he joined HotwaxMedia, he's missing I guess. Someone in the PMC should stand out. Jacques Le Roux or Scott Gray? PMC, programmers meeting committee? If so, it's a quite pitty for an ERP platform. :) Kind Regards, Shi Yusen/Beijing Langhua Ltd. 在 2008-11-15六的 13:46 -0500，Joe Eckard写道： > On Nov 14, 2008, at 3:41 PM, David E Jones wrote: > > > > > On Nov 14, 2008, at 9:46 AM, Adrian Crum wrote: > > > >> David E Jones wrote: > >>>> I don't mean to dilute the framework release effort. But at the > >>>> same time, it seems to me issues are coming up in R4 that have > >>>> been addressed in the trunk. > >>> While to some extent this depends on the type of issue, in general > >>> issues in the 4.0.0 branch should be fixed in that branch by the > >>> "sub-community" that has formed around the branch. If things are > >>> not getting fixed, to me that means the branch has not attracted > >>> enough of a user and contributor community. I don't know how to > >>> fix that problem... > >> > >> It is true that most of the bugs discovered in R4 are fixed as they > >> come up. I was thinking more along the line of the kinds of things > >> that were corrected by refactorings and such. > >> > >> I've run across a number of people using R4 and service providers > >> who are using R4 for their customer's deployments. In addition, > >> Opentaps is based on R4. So, there is a sizeable R4 community out > >> there, even if they aren't vocal on the mailing lists and such. > >> > >> I guess the goal or purpose of a Release 5 would be the same as > >> Release 4 - to provide the opportunity to build on a target that > >> isn't moving. > >> > >> I agree that there needs to be a community of people who want it > >> and are willing to support it. I was just tossing the idea out > >> there, but at this point in time there doesn't seem to be much > >> interest. > > > > These are good points Adrian. Don't let my "Devil's Advocate" > > approach scare you away or make you think there is no interest in > > doing these. I imagine there are many people who would like to see > > release branches happen. > > > > Part of the reason I wrote some doubts about it is that there is an > > open source mantra of "release early, release often" and I was > > wondering about that... What if we took the opposite approach of > > "never release"? It's the total opposite extreme and I'm not > > completely sure I like the idea, but it has some really interesting > > points. For example it encourages: > > > > 1. community interaction, even for those who are just "users" and > > not sending things back > > 2. frequent upgrades by all users to resolve issues > > 3. community responsibility, rising the priority of things like > > automated testing, and giving people more reasons to get involved > > with that testing and contribute tests > > 4. base application design decision refinement to help people with > > regular updates and resolving issues while not creating new ones > > 5. something the press can write about that is very different from > > things done in other places > > 6. a social experiment in collaborative enterprise software that is > > yet unseen in the world > > > > Of course, there are disadvantages, like: > > > > 1. a smaller user community because the prospect is scary > > > > Maybe that's it. I really think that if as a community we work more > > on automated regression tests and such we'll have a higher quality > > of software in the trunk than is in the release branches, partially > > because of what Adrian mentioned (and I alluded to) where certain > > types of issues require a lot of refactoring and aren't simple fixes > > that can go into a release branch. > > > > Anyway, something to think about. In a way doing release branches > > breaks important aspects of the "never release" approach because > > things like #1, #2 and certain of the others won't happen, or won't > > happen as much. Actually, it applies to more, maybe especially #3. > > If we never release, developers have no excuse of making things > > unstable, or committing without thinking about things, or throwing > > stuff out for they are designed well. There is no excuse of "if > > people want something stable, use the release branch, and leave us > > alone!" > > > > I'm still for doing another release branch early next year (and > > continuing with 18-24 months between branches), unless a lot of > > people find the "never release" philosophy interesting. > > > > -David > > > > (disclaimer: one guy's opinion, grain of salt, etc.) > > Speaking primarily as an end user, the "never release" approach that > the project is currently taking encourages me to isolate my code as > much as possible, and discourages frequent upgrades. It also > encourages me to cherry-pick bug fixes, which can make it tedious to > construct patches to send back when I find new bugs. > > Sometimes I like to imagine a world where OFBiz has major, minor and > point releases (with release notes) similar to what is described at > http://commons.apache.org/releases/versioning.html > (with the compatibility types redefined in OFBiz terms). For > example, any change that modifies a service's signature, or the data > model might require a new point release to include any outstanding bug > fixes, then a new minor release with a simple upgrade instruction for > that change added to the release notes. (in other words, > incompatibility would be the determining factor for minor & major > revision number upgrades) > > With something like that in place, I could feel confident upgrading > from a theoretical version 4.0.19 to 4.0.23, knowing that nothing > should break, and I don't need to install new seed data or worry about > data model changes. If I wanted some new features in 4.1.x, I would > need to check the release notes to see what incompatible change > prompted the version increase and make adjustments and an upgrade plan. > > Maybe this approach just isn't feasible for any number of reasons, but > I have always wondered why there doesn't seem to be any discussion of > something similar whenever the topic of releases are brought up. > > > -Joe
