[Cuis-dev] On complexity and growing system Was: SqueakComptibilityPackage for 6.2

Juan Vuletich juan at cuis.st
Tue Mar 5 06:13:14 PST 2024

Hi Folks,

On 3/3/2024 12:40 PM, ken.dickey--- via Cuis-dev wrote:
> On 2024-03-03 04:39, Hilaire Fernandes via Cuis-dev wrote:
>> .. what could be done is to organize how the community keeps up to 
>> date packages for a given Cuis stable release. For example, should we 
>> have dedicated repository matching a Cuis release to copy there 
>> packages tested, and if necessary patched,  as compatible with the 
>> given Cuis release. T
> Note that Packages can specify lot only the minimum release number but 
> the maximum as well.
> E.g. we could have a contributed, MaintainedPackages directory 
> associated to a particular release (e.g. 6.2) for packages with the 
> same names as cuttent/rolling (e.g. 6.3).  The 6.2 packages would have 
> the maximum set and the 6.3 have the base as 6.3 but no maximum.
> As we get more package "splits" (maintained stable vs current), we 
> might have to adjust to a more refined "search local" strategy.
> I suspect a MaintainedPackages directory as part of a stable repo will 
> just work for most use cases,
> $0.02,
> -KenD

I agree this is something we need to address. Current suggestions are:

1) A new repo for community supported packages for each stable release

2) Just a folder in the stable release repo.

I don't like 2, because it is effectively saying that those packages are 
part of the stable release. I prefer to keep them separated. Still, I'm 
not sure a single repo is enough. Currently we have dozens of repos, 
some part of the Cuis-Smalltalk organization, some owned by community 
members. But maybe, for a start, it is enough with a single repo, with 
folders named after existing repos. For instance:

repo Cuis-Smalltalk/Cuis6-2AdditionalPackages
- Measures/
- Calendars/
- OSProcess/

You get the idea.



Juan Vuletich

More information about the Cuis-dev mailing list