WTP Patch Process
When a severe problem is found in a current maintenance release, WTP may decide to produce an individual patch for the problem. Patches will only be made for the most severe problems, when regular maintenance is either not planned or will not be available in a reasonable amount of time.
Patches can be made on all previous WTP maintenance streams (e.g. 1.5.5 and 2.0.2), but there must be a significant reason why the end user/adopter cannot move to the latest service stream.
WTP will not produce patches for previous maintenance streams when a newer maintenance stream is available - e.g. we will not patch 2.0.1 now that 2.0.2 is released.
What is an "official patch"?
Under some circumstance WTP may produce a "feature patch" which typically includes exactly one jar, that has a fix for exactly one bug. These are done for bugs which happen to be considered extremely severe or blocking -- but may not even apply to all installs, or all users. So, as a general rule, they are not to be installed by everyone ... but any bugs fixed by patches will be fixed in the next maintenance release, if there is one ... though the exact fix might be different.
While few, it is important to create and apply these in a controlled, repeatable process in order to maintain product level professional quality. For example, it is important to compile with exactly the same compiler, and exactly the same "pre-reqs" that was used to create the original build.
Build vs Update site
We will decide on a patch-by-patch basis whether each fix is critical to end users (e.g. deletes user data) or only adopters of WTP (e.g. failing API). Based on this, the patch may be placed on the WTP update site for all users, or only built and made available via download.
Information on creating patches for WTP 2.0.2: