Status: Delivered
By default, we will take the previous version after another checkout of a component. It would be helpful if this frequent process could be done in one workstep.
If a component during its modification was changed at the baseline, the new baseline version of the component must be taken over again in the package via checkout. Afterwards the developer will check the last modification version against the new baseline version.
Our standard process is, the previous version is reactivated in the package after the checkout.
Because we process a large amount of components in this way, it would be helpful for us to be able to do this in one work step (checkout and reaktivating the last modification version).
I think this means the following:
A baseline component is checked out into a package and modification is underway.
In the meantime, in a different package, modifications are completed and then baselined.
This now invalidates (synch10!) the under-development version in the first package.
The only way to resolve the synch10 is to save off our current version, checkout the freshly updated baseline version over the top, then re-apply our development to-date carefully making sure that we merge the changes as we go (i.e. not just a copy over the top).
You would like some mechanism of doing this without having re-check out the new baseline version. I think that is what is being asked for.
Now, we have a similar situation in our own use of ZMF all the time, but we use ERO.
In our case the checkout/merge issue occurs when a hotfix is applied to a prior release (and the current release).
We then include this latest change in our working copy of the component before we add our changes back into the under-development release package. So all is correct as far as the code is concerned.
However, this still leaves audit thinking we have an ERR0417 situation (ERO equivalent of a synch10), because the component we based our original checkout on was changed (by hotfixing it in a prior release).
In ERO we introduced the C3;5 option (against a release package) to allow the developer to indicate that they are satisfied that they have incorporated the latest set of changes in our version of this component and that the ERR0417 situation should not now be flagged by audit. The C3;5 option manipulates the ERO meta-data to make it look like the hotfixed version was checked out again and the ERR0417 situation goes away.
I believe this request is for a similar facility to be extended to base ZMF in respect of synch10s
Will OP (or somebody) please let us know if I have got this wrong ?
Status: Delivered
By default, we will take the previous version after another checkout of a component. It would be helpful if this frequent process could be done in one workstep.
If a component during its modification was changed at the baseline, the new baseline version of the component must be taken over again in the package via checkout. Afterwards the developer will check the last modification version against the new baseline version.
Our standard process is, the previous version is reactivated in the package after the checkout.
Because we process a large amount of components in this way, it would be helpful for us to be able to do this in one work step (checkout and reaktivating the last modification version).
This change will be delivered in ZMF 8.3
