Hello,
On 2019-12-30T17:51 Eliot Miranda eliot.miranda@gmail.com wrote under the subject "[BUG] Cannot compile cascade sent to block":
That suggests we switch over to a variation of inbox for the release process. We could provide releasebox or done such (I would call it release) and only commit things good for the release. But in thinking about it it’s a bad idea. It means a lot of work to change ones working images from trunk to releasebox and back. However, if in 5.3 we provided a bulk change operation for the Monticello browser I’d consider it. Has anything like this been discussed? (we should change subject to continue...)
As long as the number of commits to manage during and after a release is no too big to look through, I think there is no immediate need to act.
Other systems use branches to deal with this. Either in the version control system or in the code. Many Git workflows have some kind of release branches on which you finish releases, and some kind of development mainline which comes closest to the non-release function of Trunk.
It seems like branch management is easier in Monticello with separated repositories. Same work in different repositories on the same platform sounds like forks of a project on GitHub to me. Eliot's concern is about changing images to follow a different repository. I think this is conceptually equal to switching the branch that the image should follow (update stream), including the loading of changes to check out the target branch.
Of course, the switching would fail if one is not careful to provide proper migration code together with breaking changes.
This is only relevant for long-lived/valuable images. In a workflow with throw-away images you would just build a new one that is based on the other repository/branch.
Monticello configurations that can be loaded and implicit configurations for the update stream are already there. What would be missing is a simple UI to perform the switching. Anything else?
It might make sense to recollect the requirements for such a facility, also to assess its value. For example, should it support only to "upgrade" an image (from Trunk to a release with a higher aggregate version number, from a release to Trunk, from release to a later release) or also to "downgrade" an image (from Trunk to any release, from one release to a previous one)?
Kind regards, Jakob