This page uses frames, but your browser doesn't support them.
When LIFEsource is used to download an upgrade from the client's
registered QA system, it will pass a command to TASKfit to automatically
change the Upgrade Status to "Closed". This change will be
recorded in the status history as normal, and the username will be set
to "LIFESOURCE". (3487)
3. Failed Upgrades
Wherever possible, a failed upgrade should be corrected and
re-submitted. It should not be replaced by another upgrade. (4648)
4. Display errors during Roll-back corrected
During roll-back, the cursor will now show as a timer and the
[Roll-back] button highlight has been corrected. (5664)
5. Program already in the upgrade
From LIFEedit, if you add a program to an upgrade that already
contains this program, the existing version number will be updated and a
warning message will be displayed. (5665)
6. Not the expected version: confirming existing process
If the version of the program being downloaded from a given
environment does not match the version number shown in the upgrade, then
the upgrade will fail. This ensures that the Upgrade is always built
with the version specified. NB - LIFEsource will not load the backup
7. Memory violations fixed
Memory problems reported locally and by Pipal have been addressed.
Please report any further problems.
8. A retry button for apply and download functions has been added.
9. Rollback now displays each step, like the Apply function does.
10. Suggestion : inserts from ARev
These have to be added to the upgrade separately, rather than having
them added automatically when a dictionary item is added.
11. No changes allowed if an upgrade is closed
If an upgrade is closed you must move it back to Logged to work on
it. Nothing can be added after it's gone from "Logged" to
anything else. NB - this does not stop the actual items being edited -
but this is for a later phase in conjunction with LIFEedit.
12. Reviewer comments in consolidation
LIFEsource has been modified so that when one upgrade is drawn into
another one, any reviewer comments will also be copied over. However
this will not be switched on until the associated release is done in
13. Usage note on removing items
Don't remove items from an upgrade if it is going to be sent again.
If the client doesn't roll back the upgrade before the next update is
received, re-applying the upgrade may leave the client with an incorrect
version of an item since it won't be overwritten.
14. Suggestion to add time/date to items to show when added
Since an upgrade can only have items added when it is logged, this
can be checked against the upgrade status history. So it doesn't seem
necessary to add the time for each item. Further feedback welcome.
15. Upgrades that fail
You do not need to roll back an upgrade if it fails. You will be able
to re-apply a later version of the upgrade, as long as each item either
a) is identical to what is there, or b) has had its version suitably
incremented. If you DO roll it back, you have the opportunity to
supercede that upgrade if appropriate. If you do not, however, you are
less likely to experience version conflicts.
16. Client search on upgrades
Clients will be able to inspect upgrades from FIT, and search on the
contents, once each upgrade is imported. But they will not be able to
edit them (they will get an error message, rather than a blank form as
before, if they try to do this). Full details of import facility to
follow in the user notes.
17. Form shown on opening
The "choose upgrade" form now shows on opening LIFEsource.
18. Superceded when consolidated, and details stored
When an upgrade is drawn into another one, it is set to
"Superceded". Also, it is not possible to do this unless the
upgrade is already at "Passed Code Review." Finally, the
number of the target upgrade is recorded in the superceded upgrade.
19. Program for listing versions of upgrades
This new feature has been incorporated into LIFEsource as a new
20. Filter now includes an option to display only open upgrades.
21. User notes
Fully updated user notes and client user notes will follow by the end
of the week. These have been overhauled, with extensive help and
suggestions from Siobhán and Toni, to be more user-friendly. We are
also experimenting with the use of limited screen prints, which were
excluded before because we were concerned the document would be too
large, and may require frequent updating. Feedback welcome ... solicited
SOME ITEMS UNDER CONSIDERATION FOR THE NEXT RELEASE
Prevent downloading of any upgrade from the QA environment unless the
related WTI is at status "Passed QA" (specifically needed for
consolidated upgrades and all related WTIs). It's possible it should go
the other way: prevent moving a WTI on to "Passed QA" until
its upgrade is downloaded. In any event, there will be some combination
of upgrade status and WTI status where the upgrade is sealed off, so
it's safe to carry on development elsewhere, but such that you cannot
download it unless some specific trigger has been set.
Status "sent to client" is being added to TASKfit and once
it is there, a message will be generated when an upgrade of this status
is rolled back from our QA environment.
To pull in an upgrade for consolidation, not only must it be
"Passed Code Review", but the upgrade cannot be at status
"Sent to Client" and it cannot already have been downloaded
from QA (this is why it is still allowed to consolidate even if the
related WTI is not at "passed QA"). Otherwise you'll end up
with problems on site when you check inside a program to see what
upgrade it belonged to - try to roll back that upgrade - and find that
it was never applied, because the whole thing went on to be
consolidated. Similarly, you should not be able to go from "sent to
client" to "Superceded". It must be rolled back (which
will trigger a status change in TASKfit), and the client must roll it