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