Releases and Planning

A short sketch of the current release plan.

Minimum Viable Product

The minimum viable product will consist of two releases.

Alpha

Currently we have public alpha release. This release should provide everything to work comfortable with modules.

Alpha 0

This version is already out in the wild.

Alpha 1

Alpha 1 was oppublished on 2021-05-10.

Features to be – or already – implemented are:

  1. Added a refactoring that enables the user to copy a class from one module to another or to copy a global class into a module.

  2. Added access-level. Not sure if these will stay.

  3. Added a wizard to help users deal with undefined global, e.g. captial names. The wizard tries to import the right classes from other modules with the users’ help.

  4. Explained the semantics of modules in more detail.

  5. Implement SqueakJS at http://haver.klix.ch as a spike. I would be cool if users can test Haver in their browsers. Will be done once this release is out.

  6. Check whether the latest VM compiles on Linux, if yes merge the VectorEnginePlugin changes into a new branch and rebuild everything. This will probably postpone the release date to 2021-05-14 (one day). No joy on this one, include order was fixed in the Squeak-VMMaker, but not in the Cuis-VMMaker.

Alpha 2

Will be released on 2021-05-31.

  1. Invested a day into other OODBMS options. Philip was not successfull in porting Magma. I came up with a simple object store called PlanE.

  2. Started with a (video) tutorial about a simple TODO-list. I am not satisfied with my videos, the lack explanatory text and maybe audio.

Alpha 3

Will be released when I found some means for better demos.

  1. Use CodeRockets’s projects to implement demo environments, that are better than videos. This was not implemented, due to lack of community interest in |Haver|.

  2. Add support for private- and internal extension methods to the compiler. Split the HaverCompiler- and the Modules- packages into a Compiler and a Modules package proper and an access-level package.

  3. Implement integration packages that can be used to develop changes to Cuis in a package that is integrated later, removing all extension methods and re-categorizing new classes. This was implemented in the Alpha 4 release.

  4. Create Haver’s image upon first start on the users machine. This way we only need to distribute one image. This is implemented in the Alpha 4 release.

  5. Document the maturity of the packages included, especially mark the work in progress packages as such. Postponed to Alpha 5.

Alpha 4

Image management.

  1. Create an image management and update application. This will be postponed to the Alpha 5 release and only be implemented if there is community demand.

  2. Design and implement wrapper packages that are loaded before a Cuis package is loaded. This package will define exactly one Module that binds every global definition of the package filed in. Use special meta-classes. that file-out stuff just like a Cuis class. This feature will not be implemented. I will implement an “export to Cuis” feature.

Alpha 4.1

Image management.

Fixed some bugs not caught by quality control.

Alpha 5

  1. Application delivery. Please note, that these features will only be implemented, if there is sufficient community demand.

    1. Create an image management and update application.

    2. Find some means for application delivery.

      1. Give the old Squeak SystemTracer a shot. Invest up to two days in getting it running. If this is successful invest another day to get rid of the ModulesTools-module as a POC. If anything of this fails we will deploy bigger images.

      2. Check whether we can generate an Inno Setup based installer. I did this once for a Python project, it worked well.

      3. Create self-mounting fuse-based zip-file. I already did some experiments with archivemount. A zip file can be appended to executable and the resulting can be made mounting itself. Haver can be started from the mounted file-system, but has problems writing it’s change log. With some fixes to the image and archivemount ‘s main this should work Big advantage: Users can generate one-file-apps with additional tools. (Look Ma, no compiler, no AppImageKit :).

  2. Better Preferences handling.

Other things to be done in parallel:

  1. Ask the Cuis-community, whether they would support either

    • an Haver-based AppStore – HaverSilo – for images and packages. This will be based on some P2P-protocol.

    • or if they would rather like some portable means to distribute single file applications.

    Especially ask whether they would support a crowd-funded project, that provides long-term-support. After all the list of dead Smalltalk projects is quit large. I am still under the impression that Haver is not mature and complete enough to ask.

Anything MacOS related will require external funding. I only have two broken Macs and can not afford a new one.

Beta

There will be a beta release. It will include a tutorial with to create a simple calculator application.

Release Candidate

The release candidate will be geared towards development of simple standalone application. Haver should help a single programmer, or a small teams of programmers, to develop applications.

Therefore it should have the following additional features:

  • A (simple) object oriented database. Currently there is a string preference for porting Magma to Cuis/Haver.

  • Some means to distribute applications for Linux. Hopefully more than just zip files.

  • Maybe some means to create windows installers.

Alternatively, if I can obtain (crowd) funding for the single file idea application idea that one may be included.