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 and github 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?