David,
I will bite on this discussion. (Note- I am a long time customer here.
I am not trying to shot the messenger, but the messenger offered to
converse with us... So... here we go.)
I think the whole problem is the difference between revision and
version(or build) numbers. I can understand how some non-programmers
can get confused about these ideas. However, BMC should be able to
help their customers Admin/Developers understand the difference.
- Enter my definitions -
Note: I think these definitions are not limited to "just me". I think
they are fairly commonly held ideas. (But I could be wrong. If I am, I
am sure someone from ARSList will point that out. :) )
Every time a developer changes anything about any file that roles up
into one or more product/part/widget(s) that sounds like a revision
number increment to me. (and the revision number schema should really
only depend on your internal source control system. Ideally, that
could still be visible to end customers, but maybe only for diagnostic
reasons.)
When the vendor decides to take the current "best we have" set of
files and stamp it with a new "version number" then that thing as a
whole (AKA: a build) is the sum total of the whole ball of wax of
those widget(s) that they are going to be selling as version "X".
Version numbers should be (IMHO) "Major.Minor.Patch". ( BMC uses
something slightly longer than that.)
A patch should have a defined, and published, "base"(starting point)
that it can be applied too.
Remedy's "base" has always been "any previous version".
So the patch gets you from where you are to the version your
patching too. (That is just a simple mater of history.) If you are
running v4 then go install v7.1 on top of it. The patch/installer
should do each upgrade between 4 to 5 to 6 to 6.3 to 7 and finally to
7.1. Ok... Ok... So v4 to v7 really is not supported due to the
limit on the number of major releases that the patch/installers will
be supported to work on. ( Yea.. I understand that.) But you can go
from v4 to v6.3 then run a second installer to go from v6.3 to v7.1.
However, the idea is that _any supported version_ should be a valid
start point for the supported patch/installer.
I believe there is no need to have all independently sold products to
be released for every minor or patch version. However, the thing that
is sold as a "Quantity 1" should be internally consistent with all of
it's parts at all releases (Major, Minor AND Patch).
I believe there is no need to have all "version 'x'" releases be
compatible with each other across independently sold products. (But
that can be a nice to have condition for marketing reasons.)
- Exit my definitions -
In your example... lets talk though a specific existing example ( with
a few more releases between the start and stop versions)...
There are documented problems with only upgrading some components
across some patch lines. Like between 7.0.01 patch 003 and 7.0.01
patch 004. Presumably all of the affected parts were patched in
"7.0.01 patch 004", and would be in that patch. But what about the
customer who a jumps from "7.0.01 patch 003" to "7.0.01 patch 009"?
NOTE: All referenced data below was acquired from the "patch download
site"('Area' field) and only slightly reformatted to try to align the
part in the patch into a consistent order. Some of the abbreviations I
did not try to expand because I thought they were to ambiguous.
Patch 003: Server, Admin Tool, User Tool, Email, Web, Approval, Migrator
Patch 004: Server, Admin Tool, User Tool, Email, Web, Migrator
Patch 005: Server, Admin Tool, User Tool, Email, Web, Approval, Migrator, Assig
Patch 006: Server, Admin Tool, User Tool, Email, Web, Approval
Patch 007: Server, Admin Tool, User Tool, Email, Web, AS, AE, Flashb
Patch 008: Server, Admin Tool, User Tool, Email, Web
Patch 009: Server, Admin Tool, User Tool
So I want to point out that:
) "7.0.01 patch 009" only patched a few of the components patched in
Patch 4. (Missing: Email, Web, and Migrator)
) there were additional components patch in other patches (like
patch 007) that were also not "patched" in 009
So if a customer jumped from Patch 003 to Patch 009... they would not
get upgraded patches for...
Email, Web, Approval, Migrator, Assig, AS, AE, Flashb
That would leave them with a Mid-Tier = Patch 003 and an ARS
server Patch 009. A combination that has known problems.
That sounds like a really bad condition to me.
And I want to point out that if you look at patch 004's download
directory then you do see the Approval Server in the patch 004. Even
though it is not identified as part of patch 004. (Which is the way it
should be. Because the Approval Server is no longer the FCR it is
Patch 003. Well, or it was patched and the list of things patched in
patch 4 is wrong. Which after reviewing the Read me suggest that a bug
was fixed in the Assignment engine in patch 004 and the list of items
patched is wrong. Drat. I hoped that would be a good example of how
BMC Remedy "use to do it right". Oh well.)
FWIW: Patch 009's download directory only has the Server, Admin Tool
and the User Tool.
As you have described the current condition of BMC Remedy patch
process.... I also wonder if the "installers" ( that are part of the
released patches) are possibly just as "lacking" in some parts of
those things that are being installed? Can a customer be certain if
Approval Patch 005 actually has all of the Patch 003 code in it? ( I
have seen bugs return in a "skip one, or two patch versions" pattern
before.)
It really means that a customer has to read/check/analyze all patches
between the release they are using and the release they are going to
move too. ( That really seems silly and error prone to me. )
If that is how BMC think software release should be done, then there
should at least be a small tool (AKA: An ARS form) that can be used by
the customers to identify "Start at version", "End at version" and
"You have these things installed on the server".. --> "Here is your
list of what patch(es) you need to install and the order they need to
be installed so you can get there."
But maybe it is just me.....
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.
On Wed, Sep 10, 2008 at 3:45 PM, Easter, David <[EMAIL PROTECTED]> wrote:
> (Note - I am the messenger here)
>
> Currently, patches are "cumulative" for a given component within a patch
> - however, if a component is not modified in a patch, then it is not
> included in that patch. For example (and this is a made up example):
>
> Patch 001 - User Tool, Mid-Tier and Server changed. Patch includes
> folders for User Tool, Mid-Tier and Server
>
> Patch 002 - User Tool, Mid-Tier and Assignment Engine changed. Patch
> includes folders for User Tool, Mid-Tier and Assignment Engine. User
> Tool and Mid-Tier changes also include any changes done in Patch 001.
>
> Patch 003 - Mid-Tier, Assignment Engine and Server changed. Patch
> includes folders for Mid-Tier, Assignment Engine and Server. Mid-Tier
> also includes changes done in Patch 002 and Patch 001. Assignment
> Engine also includes changes done in Patch 002. Server also includes
> changes done in Patch 001.
>
> etc...
>
> So in this case, you'd need to install Patch 002 and 003 to get the
> cumulative updates to each sub-component. You wouldn't have to install
> Patch 001 because everything in Patch 001 (User Tool, Mid-Tier, Server)
> was cumulatively updated in a later patch.
>
> With the newly developed installer being tentatively aimed for AR System
> 7.5.00, BMC may have a chance to re-visit this approach. I'd certainly
> be interested in the dialog around this if you all wish to discuss it.
> Here's some points to consider:
>
> 1. Some consider "cumulative" to mean inclusive of all patches prior -
> even those components that have not changed.
> 2. However, including things that haven't changed from the last patch
> could cause testing organizations to question that "nothing changed" and
> therefore force a retest the component (and incur that expense)
> 3. Some customers do not install the base product and then patch - they
> go to the patch site and install the latest patch since it (typically)
> contains every component needed. Knowing that a patch doesn't always
> contain every component, sometimes this may require the installation
> individual to get multiple patches to get all of the components.
>
> Other points, I'm sure, exist as well.
>
> Thanks,
>
> -David J. Easter
> Sr. Product Manager, Solution Strategy and Development
> BMC Software, Inc.
>
> The opinions, statements, and/or suggested courses of action expressed
> in this E-mail do not necessarily reflect those of BMC Software, Inc.
> My voluntary participation in this forum is not intended to convey a
> role as a spokesperson, liaison or public relations representative for
> BMC Software, Inc.
>
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:[EMAIL PROTECTED] On Behalf Of Axton
> Sent: Wednesday, September 10, 2008 12:01 PM
> To: [email protected]
> Subject: Re: FBserver not in AR 7.1 patch 3
>
> Patches are supposed to be cumulative though. If fb was in patch 2, I
> would expect to see it in patch 3.
>
> Axton Grams
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
