[squeak-dev] SqueakMap release versions (was: OCompletion package)

Chris Muller asqueaker at gmail.com
Fri Jan 4 17:05:11 UTC 2013


> I am doing what you suggest, make a new release of each package for
> each new release. This is actually a change from the way SqueakMap used
> to work, because I used to be able to declare an OSProcess release that
> corresponded so some version level of OSProcess itself, and for that
> release I would select all the Squeak versions that I claimed were
> compatible.

I believe this can still be done through the web-interface.

> The current SqueakMap approach is more focused on Squeak versions
> than on versions of the external packages themselves, and it requires
> the package maintainer to declare a new release every time a new
> Squeak image is released. From my point of view as a package maintainer
> this is extra work, and I no longer have any way to indicate that
> a package such as TwosComplement works across a wide range of Squeak
> image versions. But from the point of view of an "app store" for
> Squeak, it supports clear identification of packages that have been
> validated for a given Squeak image version.

I can't seem to remember why I couldn't make that list a multi-select
-- it may have had to do with limits of the HTTP communication; not
sure.  In any case, I agree it seems like it should be able to do it.

> Minor annoyances aside, seeing SqueakMap updated and actively used is
> great, and it's really very little work for package maintainers to do
> these updates, so I encourage everyone to keep doing so!

Yes, SCM tools are good at SCM but we need something that handles the
"Publish" and "Consume" use-cases.

> Since you asked for long-term perspective, I will mention one more
> thing that I think is sometimes overlooked. We as a community tend to
> focus on tools and on the main Squeak (or Pharo) image, and assume
> that there is some base of highly motivated package maintainers who
> would like nothing better than to spend a few hours or days doing
> boring and annoying maintenance programming to support the creative
> endeavors of the central team. In reality, these package maintainers
> are in the same category as unicorns. There are not really very many
> of them, and they do not necessarily appear in public just on account
> of somebody wanting to see one of them ;-)

LOL!


More information about the Squeak-dev mailing list