On Nov 17, 2008, at 12:06 PM, Joe Eckard wrote:
On Nov 15, 2008, at 4:37 PM, David E Jones wrote:
(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
For me personally, nothing would really change... i.e. when a custom
application is considered feature-complete and relatively stable and
bug-free, then all OFBiz updates stop, and my involvement with the
current trunk comes to an end (for that project). There are
exceptions - when I encounter a bug I'll check the trunk first to
see if it has been fixed, or when I am catching up on messages to
the commits list I may notice an important bug fix that needs to be
back-ported right away.
This is unfortunate, because it can put me in the same position as
Markus - improvements and fixes may need to be completely rewritten
and re-tested before I can create patches for the current trunk.
(This is the case for me right now - my main codebase is pre-4.0 and
I have a few changes that I haven't had the time to rewrite and re-
test.)
Even if there were more testing in place, the main drawback to
staying current is that with each update I may be taking on new
features or applications that my business will never use, but I am
now responsible for learning about and possibly debugging, just to
maintain the (previously stable) features I have always used.
I may be biased on this, but isn't this the main argument for
contributing as much as possible back to the open source project and
staying in-sync with the community?
Really... I don't think I could have expressed this more directly
myself... you wrote very well the reasoning I use with clients to
convince them that working with the community is better than going it
alone.
-David
