Doing a release?

[Sedat Dilek]

On Fri, Sep 20, 2013 at 8:41 AM, Rich Felker <dalias at aerifal.cx> wrote:
> On Wed, Sep 18, 2013 at 06:44:15PM +0200, Thomas Petazzoni wrote:
>> Dear Khem Raj,
>>
>> On Wed, 18 Sep 2013 09:11:43 -0700, Khem Raj wrote:
>>
>> > > It'd be really nice if uClibc adopted a slightly more frequent
>> > > release schedule, to more easily allow downstream users to benefit
>> > > from improvements/fixes.
>> >
>> > I think, if we decide to do releases biannually maintaining branches
>> > for long time can be avoided. To get started I think lets start by
>> > planning for a 0.9.34 and then everyone sending the pending patches
>> > for subsequent 0.9.35 and so on.
>>
>> Since I'm not a uClibc contributor, it's certainly quite easy for me to
>> just speak, but I would like to advocate for a time-based release
>> schedule. I believe that for many projects, time-based release
>> schedules create a rhythm, that provides well-known deadlines and
>> encourages the entire community to meet those deadlines.
>
> Agreed. Time-based release schedule has worked very well for musl,
> too, but with much shorter release intervals, usually 1-2 months.
>

I recommend to read Martin's PhD Thesis on this topic.
( Martin is a longterm Debian maintainer and was also Debian project
lead, so he should know of what he is talking. )

[ QUOTE ]

Quality Improvement in Volunteer Free and Open Source Software
Projects: Exploring the Impact of Release Management

Martin Michlmayr, University of Cambridge

Abstract

Free and open source software has had a major impact on the computer
industry since the late 1990s and has changed the way software is
perceived, developed and deployed in many areas. Free and open source
software, or FOSS, is typically developed in a collaborative fashion
and the majority of contributors are volunteers. Even though this
collaborative form of development has produced a significant body of
software, the development process is often described as unstructured
and unorganized. This dissertation studies the FOSS phenomenon from a
quality perspective and investigates where improvements to the
development process are possible. In particular, the focus is on
release management since this is concerned with the delivery of a high
quality product to end-users.

This research has identified considerable interest amongst the FOSS
community in a novel release management strategy, time based releases.
In contrast to traditional development which is feature-driven, time
based releases use time rather than features as the criterion for the
creation of a new release. Releases are made after a specific
interval, and new features that have been completed and sufficiently
tested since the last release are included in the new version.

This dissertation explores why, and under which circumstances, the
time based release strategy is a viable alternative to feature-driven
development and discusses factors that influence a successful
implementation of this release strategy. It is argued that this
release strategy acts as a coordination mechanism in large volunteer
projects that are geographically dispersed. The time based release
strategy allows a more controlled development and release process in
projects which have little control of their contributors and therefore
contributes to the quality of the output.

[ /QUOTE ]

IMHO, a six months release cycle has shown good success - for
developers and endusers.
The trend in developing seems to go to a 3-months-cycle.
The Linux-kernel as an example has proven this.

Can't say if something like "Linux-next" is do-able and makes sense as
"uClibc-next".
Fact is, a lot of kernel sub-trees (features) "mature" in Linux-next
before they enter upstream.

Just my 0.02EUR.

[1] http://www.cyrius.com/publications/michlmayr-phd/