Release Dates and Schedule

Scheduled Release Dates and Anticipated Release Cycle

Since Kieker 1.0, we had/planned the following release dates:

2016/10/01 (planned): Kieker 1.14 (6 months since 1.13)
2016/04/01 (planned): Kieker 1.13 (6 months since 1.12)
2015/10/01: Kieker 1.12 (6 months since 1.11)
2015/04/01: Kieker 1.11 (6 months since 1.10)
2014/10/15: Kieker 1.10 (6 months since 1.9)
2014/04/16: Kieker 1.9 (6 months since 1.8)
2013/10/16: Kieker 1.8 (6 months since 1.7)
2013/04/17: Kieker 1.7 (6 months since 1.6)
2012/10/17: Kieker 1.6 (6 months since 1.5)
2012/04/13: Kieker 1.5 (6 months since 1.4)
2011/10/14: Kieker 1.4 (5 months since 1.3)
2011/05/19: Kieker 1.3 (8 months since 1.2)
2010/09/08: Kieker 1.2 (6 months since 1.1)
2010/03/04: Kieker 1.1 (4 months since 1.0)
2009/11/19: Kieker 1.0

The anticipated release cycle is 6 month (two release per year).

Template for a Schedule Towards a Release

This section summarizes a template for required phases and involved actions to be performed 5 weeks before a release date t. The activities are based on activities and schedules of previous releases.

1. Phase: Instantiate Schedule, Identification of Features & Bugs to Handle

Start of phase: t - 5 weeks
End of phase: t - 4 weeks
(Duration: 1 week)

Go through the list of open tickets currently associated with the release milestone and decide whether or not the ticket ought to be fixed for the release.
1. Bug/Feature needs to be fixed -> Assign to appropriate developer
2. Else -> Do anything but leaving it associated with the upcoming release milestone (e.g., move to next release)
Create a ticket which states the dates for the current release. Example for Kieker 1.5: #430

With the end of this phase, it should be clear which features and bug fixes still need to be implemented or completed. Also, the schedule for the next 4 weeks is set.

2. Phase: Feature Completion -> API/Feature/Lib Freeze

Start of phase: t - 5 weeks
End of phase: t - 3 weeks
(Duration: 2 weeks)

This is the last phase where code changes related to the implementation and completion of new features are allowed in the master branch.
Check if new versions of the external libraries used are available. This is last phase where external libraries are allowed to be replaced by newer versions.
Prepare a draft for the release notes which summarizes major new features and bug fixes. The list of release notes for previous versions can be found at: http://kieker-monitoring.net/release-notes/
Announce release date in a news post (e.g., based on http://se.informatik.uni-kiel.de/kiekernews/kieker-1-4-to-be-released-on-oct-14-2011/). The post might also announce a summary of core features.

By the end of this phase, only bug fixes are allowed. Especially, the API should not be changed. Features or changes for future versions must only be developed in separate branches.

3. Phase: Complete User's Guide and Examples

Start of phase: t - 4 weeks
End of phase: t - 2 weeks
(Duration: 2 weeks)

This includes the finalization of the document as well as testing the examples. The tests should be executed under Unix-like Systems (+Mac OS) and Windows. The examples should be executed based on nightly releases.

TODO: It would be nice to have the execution of examples for test purposes automated!

4. Phase: Testing and Bug Fixing

Start of phase: t - 4 weeks
End of phase: t - 1 weeks
(Duration: 3 weeks)

Thanks to our continuous integration setup, a current nightly release is always available at: http://build.kieker-monitoring.net/jenkins/job/kieker-nightly-release/lastSuccessfulBuild/.

The contents of the release archives are inspected automatically as part of the nightly build.

JUnit tests are executed as part of the nightly builds.

Selected TraceAnalysis features are also tested automatically, e.g., diagrams.

5. Phase: Create, Test, Publish, and Announce Release

Start of phase: t - 1 week
End of phase: t
(Duration: 1 week)

The DevGuide? includes a summary of steps to create the release archive.

Development