On Nov 15, 2008, at 1:46 PM, Joe Eckard wrote:
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.
Again just testing the idea, and not saying we should adopt it...
How would you behave if you knew there was NEVER going to be a
release, just ongoing community responsibility?
What would your involvement with the project look like? How would you
run your efforts that are separate from the project?
-David
