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
