CURRENT LIFESOURCE RELEASES

With thanks to Martin for help compiling these.

1. Upgrades can be applied to more than one environment at once

Separate the environments with a semi-colon. Full details to follow in the user notes.

2. Downloading from QA automatically closes upgrade

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 version. (6211)

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 TASKfit. (6557)

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

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

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 even.

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 back too.