This chapter describes the release cycle of a BMPx release. It explains the different phases of a release, what happens within these phases, as well as general facts about how we are making a release of BMPx.

[edit] Release Cycle

Our current release cycle is in average 1 to 1.5 months. This can vary depending upon certain conditions described below.

[edit] Release Phases

[edit] Planning Stage

In the planning stage, we pin-point features that have to be present in the next release, as well as pinpoint critical bugs (i.e. bugs that are not feature requests) with high priority, and all other bugs and feature enhancements with 2nd priority. In some cases, we also drop/not consider fixing bugs that constitute merely an inconvenience, but are not an actual crasher of the application (i.e. small usability problems). Those are, of course, only postponed, not completely being dropped.

It's hard to tell when this phase starts, but usually approximately within the last week of the previous release and goes up to on average into 1 week within the timeframe of the pending/next release.

[edit] Development Stage

The Development Stage is also a fuzzy boundary, it usually starts around the same time as the Planning Stage, but as BMPx is in rather heavy development there might be features being worked on already for months and are now finally ready for inclusion into the next release; those constitute an exception and obviously don't fall into the regular timeframe of the Development Stage. Strictly speaking though, the Development Stage is constituted of fixing reported critical bugs (see above), and adding new features that are planned for that release.

The Development Stage for the next release usually starts right after the release of the previous version, with taking on 'heavy gear' after the Planning Stage and runs normally for about 3 to 4 weeks.

[edit] Testing Stage

The testing stage is when we're done with including all the planned features. We usually try to meet our own deadline of 1-1.5 months, and hence may drop features that turn out to take too much time to get them done for this release, and instead move them into the next release. However, the opposite may happen as well: We might decide to extend the release timeframe for this release to be able to finish a particular feature.

You can however assume as a general rule that the Testing Stage usually starts 4 weeks after the Planning Stage

[edit] Freeze Stage

Once we are confident all bugs have been resolved, we put the release into freeze stage, which also means string freeze. This usually happens 1 week before release, or to put it the other way round, whenever the Freeze Stage starts, we give it one week of running, and then proceed to the release. Translators are usually informed in time before the Freeze Stage starts so that they have time to update their translations within the Freeze Stage timeframe

Freeze Stage takes approx. 1 week and is the final stage before the release

[edit] Version Release

After the Freeze Stage, we immediately proceed to the release, unless some delaying factor arises. Please see below for a detailed explanation.

[edit] Delaying Factors

[edit] Bug Reports

Whenever a bug report is issued and we can immediately reproduce it, it will be fixed as soon as possible. It is however possible that we can't reproduce it, in which case it's being set to "needinfo" (in Bugzilla terms) or in our case of Mantis to "feedback".

We usually give the respective user 1 week of time to provide the feedback we need to reproduce the bug. If we still can't reproduce the bug after this time period and we didn't get any feedback on how to reproduce it, we are leaving it open, but (have no other choice than to) disregard it for the upcoming release.

With certain critical bugs however we might extend that period and possibly (i don't think this has ever happened yet) wait (theoretically) indefinitely for feedback or do extensive/exhaustive tests on our own to reproduce the issue, which might include running the application under the same environment (Operating System) the user reporting the bug has run it including the same versions of the libraries he used, etc. If we don't have this information given by the user, then we're going to try to gather and possibly assume this on our own to be able to reproduce the bug.

[edit] Pending Features

Usually, we drop a feature and move it into the next release whenever it takes too long to finish it within the 1-1.5 months timeframe. It might, however, happen, that we extend the timeframe instead and focus on getting this particular feature done. The reasons for this are usually that some other feature depends on this particular feature/functionality and it must be included, or both features must be dropped altogether. This is a specific decision each time and no general rule can be applied to this.

[edit] Summary

2 Weeks of Planning Stage, 1 Week of this is placed inside the cycle of the previous release
3 Weeks of Development Stage. The Development Stage starts usually directly after the release of the previous version, but takes on heavy gear only once the Planning Stage is over (i.e. all features/bugs/considerations have been discussed)
1 Week of Testing Phase
Release

Retrieved from "http://beep-media-player.org/site/Releases"

64.208.172.175 Talk for this IP Log in / create account

This page has been accessed 13,520 times.

Contents

[edit] BMPx 0.13

[edit] BMPx 0.14

[edit] BMPx 0.20

[edit] BMPx 0.30

[edit] BMPx 0.32

[edit] BMPx 0.34

[edit] BMPx 0.36

[edit] BMPx 0.40

[edit] BMPx Release Process