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 back2. frequent upgrades by all users to resolve issues3. 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 worldOf course, there are disadvantages, like: 1. a smaller user community because the prospect is scaryMaybe 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
smime.p7s
Description: S/MIME cryptographic signature
