Hello,

On 2019-12-30T17:51 Eliot Miranda <eliot.miranda at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200101/9b83ccfb/attachment.html>