It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,787
×19
×1

question asked: Feb 27 '14, 1:52 p.m.
question was seen: 3,780 times
last updated: Feb 28 '14, 10:28 a.m.

Related questions

FAQ - How this Forum works

Is anyone supporting a product with individual fixes versus entire jar updates?

0
Jay Witherspoon (13●6●8) | asked Feb 27 '14, 1:52 p.m.
It seems like everyone I talk to that is developing and shipping a product out of RTC is doing their support after shipment as service packs or full jar updates or a cumulative with all changes to date.

Is anyone currently building individual fixes where you ship only the classes that have changed in regards to that specific fix?

I am not talking about shipping all changes to date, but only the classes required for that fix and any prerequisites (previous fixes that altered the same files).

Comments
Jeff Care commented Feb 27 '14, 5:05 p.m.

Sub-JAR fix granularity assumes you have the installer/updater infrastructure to handle that granularity...

(checks bluepages) I'm assuming you're using IM?

2 answers

Most liked answers ↓|Newest answers|Oldest answers

0
permanent link
Jay Witherspoon (13●6●8) | answered Feb 28 '14, 10:28 a.m.
We have been using this fix approach for many years in some very large products in IBM (like WebSphere).  We have tooling to determine the prerequisites, build and package the fix and tooling that takes that metadata into account during install to prevent regressions from overwriting the previous fixes, etc.  However, that tooling was all written for CMVC which is an IBM product that is no longer supported.  I am trying to safely use this same method of support using RTC and cannot find a way to reliably determine the prerequisites.  We cannot change our entire support strategy because we had to move to RTC.

So, I was really looking for someone who is supporting products in RTC using a similar approach to discuss how the managed to determine the prereqs.
2
permanent link
Piotr Aniola (3.7k●1●17●38) | answered Feb 28 '14, 4:36 a.m.
We do not do that, as
1. we do not have a mechanism/tools to handle it
2. changes made to the environment would not be trackable - right now the installer updates the metadata (even for hotfixes) that allows us to track fixes. With the method you propose, there would be no way to tell for example which fixes will be overwritten by an update, or by a subsequent fix and so on.
3. risk involved - because you would effectively end up with a custom version of the jar (and the whole product) that noone else has tested before (especially after you accumulated more than one fix per jar)

To sum up, I would highly discrecommend considering this approach.

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.