On Fri, Jan 04, 2013 at 08:49:53AM +0000, Frank Shearar wrote:
> On 4 January 2013 08:02, H. Hirzel <hannes.hirzel at gmail.com> wrote:
> > The problem is that Jeff does not have the right to do that
> 
> Yes, and I can't help with that.
> 
> > and he
> > likes to have some guidance....
> 
> I thought that's what I did? "Don't edit the release, make a new one instead" :)
> 
> I don't know how to handle versioning things for packages that work in
> multiple images, but perhaps Dave can suggest something? OSProcess has
> had to work across multiple Squeaks for ages.

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.

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.

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!

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 ;-)

Dave