Am Sa., 19. Feb. 2022 um 14:05 Uhr schrieb Jörg Belger <unique75 at web.de>:
>
> Let´s assume we allow multi-repository prerequisites. The Core team adds „package P2“ [which depends on P1, JR] to its supported things, because it is a wonderful tool and put it into the Core repository R2.

Who is the "Core team" and what is "The Core" here? VisualWorks and
the VisualWorks team? Then the equivalent would be the Squeak core
developers and R2 would be the Monticello Squeak Trunk repository. I
will assume that in the following.

> But this package P2 depends on package P1 which is on repository R1. The repository R1 is maintained by one private person and 1 year later the repository is deleted or moved to another location or the package P1 there is broken and unloadable etc. etc. etc. There are many reason for that, e.g. the one person has another working style, another quality assumptions etc.
>
> What is the end of this story? You have a package P2 on the Core repository R2, which is supported… but it does not work, coz side dependencies are out of control and does not work anymore.

Whoever includes P2 in the Squeak Trunk must also include P1 or they
will have done something wrong, since the Trunk is not meant to depend
on stuff from any other repository. :-)
Ideally package maintainers make plans about such situations for their
third-party dependencies as well.

To the rescue, Monticello has a package cache on each machine (or
rather, under each directory in which Squeak is run). Whoever
installed P2 into their image will also have loaded P1 when that was
still available, so a version of P1 can likely be found in the
Monticello cache on somebody's disk. That may not be the perfect
backup, but better than nothing to retrieve the code.

> This is exactly the situation where I run often into when I tried to load things. The URLs in the configuration of supported things does not work anymore or the version did not match anymore, I got always loading hell problems and that is just frustrating. You want to load something and everything you try is not working.

I am sorry to hear that and I know this is frustrating. But alas I
must nitpick on the word "supported". Supported by whom? Everything
that is outside of the Squeak Trunk is not officially supported by the
"Core" Squeak. That includes
http://www.squeaksource.com/MetacelloRepository and the
ConfigurationOfXyzs, which can be found there. The responsibility to
keep these things up to date and running lies with the owners of these
projects/packages. And it is not unlikely that many have been
abandoned over the years.

Some projects are semi-endorsed by Squeak as there are UI elements or
code in the Trunk meant to load them easily: Metacello, the FFI,
Autocompletion, the Git tools, Inbox Talk, OS interfaces, ... It is
likely that any breakage there will be noticed sooner than in any
packages that have just been lying around somewhere for the past 10
years, but which can still be found on SqueakMap or in the
Squeaksource repositories. But even these semi-endorsed projects are
mostly maintained by just one individual each. Should they lose
interest or become unavailable and something breaks, the Squeak
community will have to see whether a new volunteer steps up, learns
the code and fixes it, or whether Squeak will lose an endorsed (but
third-party!) feature.

In SqueakMap each release of a project must explicitly "opt-in"
declare support for each new Squeak release. That is to avoid that one
gets a long list of things that are supposedly available, but which
cannot be loaded anymore because they are so old and unmaintained.


>
> One other topic I want to mention about versioning is… if we have an issue tracking system… we normally publish a bundle/package with that issue number inside the version string. That means somebody finds a bug and creates an issue 4711 and put it into the public pool. Another person can pickup this issue 4711, solve the problem and publish the changes as „package P1 V1.1 + issue 4711 1“. The last number „1“ is incremented with every publish. This is very helpful, because others see immediately that this version branch is forbidden and „work in progress“. When the issue is finished it is delegated to a reviewer or a pool, where others can pick it up and make the review. The reviewer loads the „issue 4711“ branch of the package, integrate it and publish a new trunk version of the package, in that case it would be „package P1 V1.2“. The advantage is that every time you asking yourself why a specific change was coming into a method, you can see that „issue 4711“ branch in the version history and then you can look into the issue tracker at issue 4711 what the reasons were.

The workflow can be the same in Git. Create a branch, make commits (no
need to assign consecutive numbers), have the branch reviewed&merged,
release. The only twist is that in the Git history you do not see the
branch name anymore after the branch has been deleted for good. That's
why you should include the issue reference (4711) in the commit
message, not only in the name of the branch.

In Monticello, you *could* change the name of a new version to be
something else than just PackageName-author.number, but nobody does it
except if they want to create a branch of a package.

>
> I do not see how we can work in such a professional way together when we are using emails. I am seeing often emails flying around with Review requests, but emails can be forgotten. The packages contain only some magic name, but no issue number, so the changes are not traceable from what issue they came and why and when. And please guess me, it happens often that you ask 2 years later why a specific change is inside. It is very helpful then to have the documentation history in the issue what the person thought 2 years before.

Yes, such things do happen occasionally. ;-) To deal with some of the
issues, Christoph has created Squeak Inbox Talk, a tool in the image
that postprocesses the mailing list messages to help keep track of
some things. Other than that, there are still the commit messages in
the Monticello package histories, so ideally one can also find the
reasons for a change there.

Kind regards,
Jakob



>
>
> > Am 19.02.2022 um 12:07 schrieb Jakob Reschke <jakres+squeak at gmail.com>:
> >
> > Dear Jörg, dear all,
> >
> > Am Sa., 19. Feb. 2022 um 10:54 Uhr schrieb Jörg Belger <unique75 at web.de>:
> >>
> >> If somebody thinks know to use Github as source code repository, I like the idea only a little bit, Pharo uses it. It has the advantage that nobody needs to run an own server at home :-)
> >> But the big disadvantage is, that you cannot think anymore in packages with its own version history like in Monticello. You need to think in repositories and branches and if you change two packages that are linked to one Github repository and you commit the first package, then I think you commit the second package too under the same version, because in reality you do not commit the package, you commit your current repository from disk to server. You lost the possibility to version each package differently.  That makes it impossible to load later packageA with version 1.5, but loading packageB with version 2.7.
> >>
> >
> > To be honest, I do not see the problem here. Smalltalk version control
> > systems almost all offer the feature of configuration maps because it
> > is often required to specify which package versions work together
> > because the packages in fact belong together. In Git and similarly
> > organized version control systems, simply every commit is a
> > configuration of the packages contained therein. If you do not change
> > packageB on your new commit in which you want to change packageA,
> > packageB in that new commit will be equal to packageB in the parent
> > commit. It will not make a difference for packageB from which of the
> > two commits you load it, so why care?
> >
> > If you want to grab a change to one package from a commit but not a
> > change to another package in the same commit -- for whatever reason
> > that the maintainer apparently did not have in mind -- simply make a
> > selective load/checkout: deselect the changes to the other package
> > that you do not want to apply to the image, just as you would deselect
> > changes that you do not want to commit when you create a new commit.
> > Or the other way around: browse the commit from which you need some
> > changes, select the package/category/class which you want, and load
> > just that.
> >
> > If the two packages are really not connected to each other and it is
> > supported to freely combine different versions of them, then there is
> > no point to develop them on the same branch or even in the same
> > repository.
> >
> >> Does anybody knows if we can have a Github repository where we can think like a Smalltalker and commit single packages ?
> >
> > It is just a matter of organizing it as such. Create a new GitHub
> > repository for each package and commit only one package to each
> > repository. The repositories are already organized under your
> > username. For everything beyond a single person, there are GitHub
> > organizations like https://github.com/squeak-smalltalk/. If you want
> > to stay within a single Git repository for some reason, create a
> > separate branch for each package and only commit a single package on
> > each branch.
> >
> > Kind regards,
> > Jakob
>