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: #. 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. #. Added access-level. Not sure if these will stay. #. 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. #. Explained the semantics of modules in more detail. #. 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. #. 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. #. Invested a day into other OODBMS options. Philip was not successfull in porting Magma. I came up with a simple object store called PlanE_. #. 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. #. 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|.* #. 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. #. 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.* #. Create |Havers| 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.* #. Document the maturity of the packages included, especially mark the work in progress packages as such. *Postponed to Alpha 5.* ``Alpha 4`` Image management. #. 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.* #. 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`` #. Application delivery. *Please note, that these features will only be implemented, if there is sufficient community demand.* #. Create an image management and update application. #. Find some means for application delivery. #. 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. #. Check whether we can generate an `Inno Setup`_ based installer. I did this once for a Python project, it worked well. #. 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 :). #. Better Preferences handling. Other things to be done in parallel: #. 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. .. _Inno Setup: https://en.wikipedia.org/wiki/Inno_Setup .. _archivemount: https://github.com/cybernoid/archivemount .. _PlanE: https://hg.sr.ht/~cy-de-fect/HaverOnCuis/browse/haver/db/PlanE.pck.st 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. .. LocalWords: Smalltalk