• View
• Edit
• History
• Print

ReleaseSchemeProposal

This page proposes a new way to coordinate Boson releases.

Current situation

It has been more than 6 months since last release and no active development has happened for several months now.
Currently latest version 0.11 was under development for nearly 1.5 years before it got released.
We should try to avoid such situations (delaying releases, development inactivity), because it results in loss of interest for both users and developers.

Proposal

We need a better way to coordinate development and releases. I'm proposing to use milestone-based released scheme:

• After every release, we compile a list of major features (actually of all bigger changes, e.g. some bugfixes might also fall into this category) that need to be in the next release. This should happen during 1-2 weeks following the release

• The list should always contain "no critical bugs" item

• Every entry in the list must be associated with a developer (or developers) who is responsible for implementing this feature
• All the features in the list should take about 2-3 months to develop, thus we'd have a release every 2-3 months. I think we mostly know how much time we can devote to Boson in next 2-3 months, so with that timeframe we should be able to make quite realistic feature lists

• Once the feature list has been finalized, it shouldn't be changed, except for emergency situations (which should be really rare), e.g. sudden lack of time or the release being delayed by a single unimplemented item

• Once all features in the list have been implemented, we will test it for about a week and then make a release
• No bigger features/changes should be implemented except for those in the list. This should make sure that the development stays concentrated towards the releases instead of everyone just picking features they want to work on most. If you want to make a bigger change, you just need to wait until the next release (<= 3 months usually)

So the release cycle would be:

• Compilation of the feature list for the next release - 1-2 weeks
• Implementing features in the list - 2-3 months
• Testing & preparing for the release - about 1 week
• Release!

Total length of the cycle would be no more than 4 months

Advantages

• We'd have more releases and less time between them -> increases interest (I hope)

• Development stays concentrated as you've got a schedule to keep up with (you define your schedule yourself though, so it's flexible)

Disadvantages

• Schedules and more strict release/development policy might scare away potential contributors (but hell, we don't have any anyway...)
• A very formal release schedule for a 2 person development team. Say, do you need a formal schedule? If so - sure, go ahead. But don't expect me to stick to it, cause I won't. I can cope with a certain level of formality, but after all the reason that I work on an open source game, is that I don't like too much formality. And I don't see the point of it in a 2 person team at all.
• The plan goes completely crazy when things turn out differently to what has been estimated. Assume your features take actually 4 months to get implemented, mine take 2 weeks (you underestimated and I overestimated the required work). What then? I should just stop doing anything for 3 months? If I am allowed (as an exception ) to make an addition to the plan: what if that project turns out to take even longer than 4 months? Maybe even because I lose interest at some point and it just gets boring (and I'm not allowed to do anything else for a while according to the plan)?
• You need to know in advance what features should get implemented

Alternative

Alternative solution would be to have a fixed-length release cycle of, say, 3 months.

This would also fix we-don't-have-any-releases problem, but it might lead to releases which don't have many new features compared to the previous release.