[lively-kernel] Release planning

[Robert Krahn]

Hi, guys -- 

I want to start a discussion of how we schedule and conduct our Lively Kernel core releases and how to make contributing to the Lively Kernel easy.

Lively Kernel core

As you may have noticed we started working son a separately maintained version of Lively Kernel core in the beginning  of tho year. You can find it here: https://github.com/rksm/LivelyKernel.

Additionally we created a tool suite for automating tasks that are required for maintenance, syncing, releasing, testing, etc. Those tools are located here: https://github.com/rksm/livelykernel-scripts

You can find the reasons for this process change here: https://github.com/rksm/LivelyKernel/wiki/Repository-Purpose

One of those reasons is to get a very simple way of installing Lively locally on your computer. On a Unix you can for example install it now from within a terminal by enter in the command
curl http://lively-kernel.org/install.sh | sh

We are still working to improve the development process when working with the local Lively version. Currently it is starting a Lively minimal server using lk server and then working with the worlds that came with the git core repository, e.g. http:/localhost:9001/blank.xhtml and running the tests with lk test. We will shortly send out more information about this process.

Everyone is very welcome to contribute to the core system. For example using the github fork/pull workflow. This proved to work very well for other systems. I don't know if it will work for Lively as well but I would like to find that out. Github has the advantage that it makes code changes very well visible and allows easy collaboration (like code reviews / commenting).

Also changes that happen to the core modules in webwerkstatt will be brought to Lively Kernel core. The lk tools ask allow syncing that has proofed to work well with the last release. I will write about a proposal of the webwerkstatt core development process shortly.

Lively Kernel versions and feature planning

We adapted a new version scheme: major.minor.maintenance. We are currently at version 2.1.3. I expect that those maintenance releases will happen every two to four weeks. These maintenance releases will mostly include bug fixes. Major releases should be for ground-breaking stuff ;)

I would propose to have minor version changes every 1-3 month, based on the number of new features that have accumulated. The releases should bring noticeably improved functionality. The main point of this mail is to start a discussion about how we can decide what features and what bug fixes should go into a release. We currently use the webwerkstatt trac system (http://lively-kernel.org/trac) and github issues (https://github.com/rksm/LivelyKernel/issues) for tracking bug and feature requests. Having two systems is not optimal and both systems lack the ability that I personally find crucial: Be able to vote on new features / bug fixes. What is your opinion about that? How would you like to contribute?

Best,
Robert


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hpi.uni-potsdam.de/archive/lively-kernel/attachments/20120412/f4af2aa1/attachment.html>