Re: Frameworks and versioning
Re: Frameworks and versioning
- Subject: Re: Frameworks and versioning
- From: Chuck Hill <email@hidden>
- Date: Thu, 5 Jan 2006 12:49:00 -0800
Hi,
I think that we are diverging from the original question. I'll
rephrase Lachlan's question as, "I have several applications deployed
on a sever and they share some common frameworks. I'd like to be
able to update one application and its associated frameworks without
affecting the other applications. What is the best way to do that?".
The core problem, to me, is one of cost. In a perfect world, where
retesting is free, I would just update the frameworks, retest the
apps, and deploy the changed bits. Mine is not a perfect world, and
if I had to run a full regression test on five unrelated applications
every time I made a change to one of them, well that would make many
changes cost prohibitive. I can't fairly charge one customer for the
costs of testing four other client's applications, nor can I charge
the four clients for testing an update they did not request. And I
don't want to do the testing on my "free" time. Testing just isn't
that much fun. Instead, I update the one application and leave the
others untouched until client requests force an update.
Unit tests go a long way toward reducing retesting effort. But they
are not a replacement for functional tests. I have yet to find (not
that I have exhausted all efforts) a way of having fully automated
functional tests for a WO app that were not more effort to create and
maintain through UI changes than they were worth. If anyone has done
this, I would be delighted to hear how you achieved this. More
delighted than you can possibly imagine. :-)
If all of your apps work together, then it may make sense to update
and test them all together. But then you don't need to worry about
versioning. :-)
On Jan 5, 2006, at 9:23 AM, Robert Walker wrote:
I personally tend to agree with Arturo. Yes it does take more
discipline during development, but I consider that part of my job
as a developer. It's vital to ensure APIs don't break with changes
and bug fixes. If changes to API are necessary deprecate the old
method, and create a new one to support the API change. The trick
is in learning to recognize when a change affects the API.
I take a different view. I am not maintaining the Sun or the WO
API. I'd rather have a clean API and force applications to be
updated to use the clean API than drag around years of cruft as
deprecated API.
Taking a look at /System/Library/Frameworks and /Library/Frameworks
you will see many frameworks written by Apple, and other software
developers. These frameworks are shared among many different
applications. Those that make up parts of the OS share it's
version number with the OS. Those that are specific to a developer
application tend to be controlled by that particular application
vendor.
As WebObjects/Cocoa developers we should use this same approach.
It seems to me the whole point of a "Framework" is to share its API
with many applications. Otherwise, why separate code into a
framework to begin with? (No intent to start a philosophical battle
here. Just expressing my opinion.)
Code reuse. Separation of concerns. Organization. All of those are
valid reasons for using a framework. And keep in mind that as the
frameworks that you mention are versioned, that implies that they do
_not_ share a common API. Otherwise, what need would you have of
versions?
On Jan 5, 2006, at 11:21 AM, Arturo Perez wrote:
Tonny Staunsbrink wrote:
Hi All
I'm don't think there is a "right" answer on this issue.
I agree, there isn't. Each of us needs to carefully consider their
situation and needs.
Embedding your frameworks solves the problem of breaking API or
introducing bugs. On the other hand it makes it cumbersome to
deploy bugfixes to frameworks (when multiple apps are using the
frameworks).
When the applications are tightly related, it does make more sense to
share physical frameworks.
It's the same discussion as dynamic vs. static linking - the same
pros and cons (well, almost) - and i think it's worth to note
that dynamic linking is used alot.
Java has only dynamic linking.
I prefer to have my frameworks deployed seperately from the
applications (due to the ease of deploying updates). The risk of
breaking API should be a matter of developer discipline ;-) and
sometimes biting the bullet (rebuilding and redeploying every app
when some used API fetaure is completly removed).
Personally, I've never liked the embedding of frameworks et al
into an application (although I did once work with a group of
developers that almost violently disagreed). I much prefer that
all applications benefit from bugfixes and performance
enhancements as soon as possible.
I do as well, provided that it is cost effective. The cost is the rub.
It does require a bit of discipline to not break things but I
think ensuring that apps get the right set of bugfixes etc is at
least as much work. Of course, if your style is deploy-and-forget
then embedding frameworks is definitely the right way to go.
I believe a healthy combination of CVS-log monitoring (read them
daily and write good ones), JUnit et al, and black-box testing
(JMeter, HTTPUnit, et al) can keep an application functioning
properly in the face of frequently updated frameworks.
What if you have not touched the application in three years? What
if you have 10 or 20 such applications? Can you monitor all the
log messages and consider them in the light of what each app does and
run all the tests and still get work done? I can't.
An interesting topic indeed!
My 2 cents.
Chuck
--
Coming in 2006 - an introduction to web applications using WebObjects
and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden