Squeak
  links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Community Requirements for a Software Catalog
Last updated at 4:38 am UTC on 6 October 2015
Many discussions occurred during 2010 and 2011 about how to improve the community's development processes, publishing and sharing capabilities, and overall cohesion and collaboration.

The following represent the requirements that were expressed by members of the community.

  1. Provide a medium that represents the universal catalog of externally-available software applications and demos for Squeak, regardless where the code for those projects is hosted (SqueakSource, SmalltalkHub, Metacello, Hasso-Plattner servers, github, etc).
  2. A tool with which Squeak community users of all levels can reliably install programs and media.
  3. Installation must occur with one-click, including all prerequisite packages.
  4. The packages presented in the list must work.
  5. When a new version of the Squeak image is released, packages that have not been retested with the new release must be excluded from the list. This is to avoid bit-rot. Thankfully, redesignating a package for the next version of Squeak is a straightforward procedure, but a crucial one because it ensures that a human spends the few minutes required to bring forward the package and make sure it works before it is presented to the world as supported.
  6. The ability to publish any kind of project that includes code and materials like graphics, videos or sound files.
  7. The ability to publish a package release with functional-longevity. It should never stop working in the particular image it is designated for.
  8. Foster community-development by providing one-click ability to merge the latest code packages with a trunk-like process per project.
  9. The ability to resurrect projects that are owned by members who have long-since departed the community while protecting the original archival legacy of the original author. Currently-active members should be able to post new-and-improved releases that work for the latest version of the Squeak image.
  10. Should be lightweight and SCM-tool-agnostic.
  11. "Distributed" / locally-cached.
  12. Should be able to post new configurations easily to facilitate quick-publication of fixes.
  13. Must be able to browse code before installing it, as a security measure.
  14. Installation steps should be idempotent in nature.

The new SqueakMap Publishing Guidelines are designed to ensure these requirements are met.