[Release] Philosophical Discussion - The updates button is useless - discuss

[Keith Hodges]

Igor Stasenko wrote:
> 2009/7/8 Ken Causey <ken at kencausey.com>:
>   
>> The 'load updates' button is far from useless.  The function of the
>> 'load updates' button is to take an image that is reasonably current and
>> synchronize it so it is up to the up to date with the in development
>> state so that we are all working in the same playing field.
>>     
Bearing in mind that we are/were aiming to produce a process in which a
new minor release could be released daily/weekly 3.10.3 , .4 .5 , and a
major release monthly/quarterly I think that this may alter the dynamic
somewhat.
> Except that it could have different sense for core developers vs
> endusers(stable image users).
> Core devs, obviously, would want to load a most up to date & bleeding
> edge stuff,
>   
Defining first what is a core dev. That would be for me someone who is
willing to take on a significant project, or what was referred to as a
"grand refactoring".

So when I am operating with my core-dev hat on I will be working on a
project which is by definition half completed, I really do not want to
have loaded into my environment someone elses half completed projects.
> while stable image users may want to update packages , which already well tested & error proof.
>
>   
I really don't think that this is a common use case. How many serious
users keep one image going and push update. I have about 40 current
images in my working directory. I frequently download a new image for
whatever takes my fancy, on average once a week. I value the fact that
when I download 3.10 I know pretty much what its foibles are even if I
don't like them.

Also the things that I want fixed in an image rarely do get fixed, for
example I waited 2 years for a fix to the annoying browser pane list box
bug, that Andreas had fixed ages ago. However now that that fix is
available on mantis I can load it, I am not behove to the guardians of
the update stream.

I can see Andreas' scheme of a whole repo for updates working much
better for updates than the current linear stream, however for pulling
apart and assembling a release I am not so sure.

By the way, a not well known feature of Sake/Packages is an #upgrade
which loads the latest of all currently loaded packages. One goal I have
been working towards is to have only one master list of Packages in the
image.

Monticello1 used to maintain its own list, MC1.5 now uses the
PackageInfo/PackageOrganiser as the master list. Sake/Packages maintains
its own list, but I plan to improve that to use PackagesOrganiser too.

Andreas wrote:
> There are two trivial ways to extend this. First is provide a list of
> > repositories that you'd like to update from:
> >
> > MCMCMUpdater updateFromRepositories: #(
> >  'http://source.squeak.org/Squeak311' "fixes released for 3.11"
> >  'http://squeaksource.com/Seaside29'  "current Seaside 2.9 updates"
> >  'http://squeaksource.com/MyStuff'    "and whatever else"
> > ).
> >
>   
Igor replied:
> This is good & simple up to the point, when the upstream updates (say 3.11)
> going into conflict either with Seaside29
And currently the standard practice is for seaside to be developed for
deployment into an image which is a well known quantity, i.e. a major
release. The same is true for all external packages, so adding the
possibility of updates is a potential source of fragility.

Edgar wrote:

> This could be nice.
> And we could have updates coming from Pharo ?

Andreas Replied:
> We could, but it requires that the people running the show provide a
> set of update.mcms. Without that it's not really feasible.
Building an image in which a couple of packages are directly loaded from
pharo's trunk would be easy for bob to do, and is anticipated. My only
regret here is that it may be quite difficult to agree on common package
boundaries.


Keith