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? <div>
<br></div><div>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"?<br><br><div class="gmail_quote">
On Fri, Jun 10, 2011 at 8:12 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On 09.06.2011, at 23:54, Andreas Raab wrote:<br>
<br>
> On 6/10/2011 0:39, Bert Freudenberg wrote:<br>
>> 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.<br>
>><br>
>> 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.<br>
><br>
> 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.<br>
<br>
</div>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.<br>
<br>
A way to discover the problems you mention would be to actually update from first principles every day. Build server, anyone? ;)<br>
<div class="im"><br>
> 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.<br>
<br>
</div>Well, it could be even more efficient :)<br>
<div class="im"><br>
> 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).<br>
<br>
</div>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.<br>
<font color="#888888"><br>
- Bert -<br>
<br>
<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Casey Ransberger<br>
</div>