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

[Keith Hodges]

>>     
>
> Keith, in Sake you can define a more complex tasks, which could
> provide a sort of an update stream in easily manageable fashion.
>
> For instance, you could have a class TaskForLoadingPackageSetX, which
> holding a meta-information how to load and/or upgrade from current
> image version to an image with up-to-date collection of packages A, B,
> C.
> Each time a TaskForLoadingPackageSetX author/maintainer updates this
> class , and enables new versions of basic packages A,B,C to be
> integrated into latest version - he simply changing the meta-record,
> or , what i think is more appropriate, adding a new method(s) so they
> appear in historical record, like:
>
> TaskForLoadingPackageSetX >> loadVersion123
> then he adds
> TaskForLoadingPackageSetX >> loadVersion124
> then
> TaskForLoadingPackageSetX >> loadVersion125
> and so on..
>
> Does this makes sense to anyone than me?
>   

Definitely some sense,

SakeTasks fundamentally support concepts like, dependsOn: , and isNeeded:

SakeClassTasks allow things like create a class if it doesn't already
exist, which you can put in as a dependent of a task that needs a
particular class. Much like "make" creates files or directories when
they are needed. Or check if the class/package/method exists before
performing the action. Of course this is minor overkill, since you could
just use code like Smalltalk at: #Bob ifAbsent: [ do stuff ], but if 50
tasks want to ensure that a class exists then the test will only be
carried out once.

For Sake/Packages the packages you define are version controlled using
MC, so we are basically taking a snapshot of the state of all packages
in time and if you want to go back to a historical snapshot then you can
load an older version of Packages-Library

However I think we can simplify the whole issue if we clarify who our
users are.

The architects develop a process and tools for the programmers to
develop a base release image, the builders in the community build and
configure derived images from pre-defined components for their audiences
the smalltalk authors and users.

Our target audience is not the end users, or even the individual
programmer, it is the builder of interesting customised images, so they
would be capable of using a less than single click solution.

If this is the case then the builder of the customised image will have
detailed knowledge of how he configured the image he published, and the
update stream might be useful to him for passing on emergency fixes to
his own users.

Keith







Keith