Ouch. Yeah, understanding what release a config corresponds to is probably
about the most important part of the "community supported" idea (unless it's
the tests.) Would it be possible to start keeping track of this stuff in the
following release?

Other than the painful update thing, are there any other actual technical
issues? Can we just add a note somewhere that says "BTW these bits
correspond with Squeak 4.4"?

On Fri, Jun 10, 2011 at 8:12 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:

>
> On 09.06.2011, at 23:54, Andreas Raab wrote:
>
> > On 6/10/2011 0:39, Bert Freudenberg wrote:
> >> Loading all packages found is not a good idea. We only want to load the
> packages mentioned in the config, and do it in the order given.
> >>
> >> What should work, IMHO, is when uploading a new config, only update
> those package versions that need changing. That is, take latest config,
> change version for the package you need updated, publish. There currently is
> no UI for this, it only allows "update from image" and "update from
> repository" which updates all packages. But if individual packages could be
> updated that should work faster.
> >
> > I have a few doubts about how well this would work. Here is why: Let's
> assume the last config had Kernel-Foo.1.mcz in it. You update happily and
> when you're done (w/o any update.mcm) you're at Kernel-Bar.99.mcz. Now you
> find that you have an ordering problem which makes it so that
> Sockets-MeToo.123 needs to be loaded before updating Sockets further.
> According to your logic, this would now mean that the MCM combines
> Kernel-Foo.1.mcz with Sockets-MeToo.123 even though you've most likely
> developed Sockets-MeToo.123 on top of Kernel-Bar.99. And if loading those
> two together will work you'll only find out if someone actually updates from
> first principles; if people keep their images updated regularly they could
> be quite a ways past Kernel-Foo.1 already and may not even notice the
> problem. I'll also point out that we've had this particular problem a few of
> times already and it was a major pain to go back and fix the configs so that
> updating from first principles works again. I really wouldn't want to make
> this worse.
>
> I see your point. We don't handle dependencies between package versions, so
> problems with dependencies getting out of sync should be smaller with more
> frequent checkpoints. It still seems somewhat accidental.
>
> A way to discover the problems you mention would be to actually update from
> first principles every day. Build server, anyone? ;)
>
> > That said, let me ask a different question: Why is it a problem to have
> 200 MCMs? If you're updating from 4.0 to 4.3 you are updating through two
> and a half versions of Squeak, work that took two years total by the entire
> community. That doesn't strike me as too much.
>
> Well, it could be even more efficient :)
>
> > The only thing I'd like to have is to be able to update such images to
> particular checkpoints (i.e., load the updates from 4.0 -> 4.1, 4.1 -> 4.2,
> etc).
>
> That should not be hard if we knew which trunk config corresponds to which
> release. Which we don't, unfortunately. There's no tagging as in other SCMs.
>
> - Bert -
>
>
>
>


-- 
Casey Ransberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110610/55c40b1d/attachment.htm