[asterisk-dev] Release schedule ?

[Kevin P. Fleming]

Luigi Rizzo wrote:
> I would like to know what is the planned schedule for 1.4.0,
> so that developers like me could know how to focus their work within
> their available time.

The planned schedule is long gone.

> It seems that the beta period has been going on for a very long time,
> yet not having a deadline for the release makes it very hard to
> organize work.

In what way? Everyone is being encouraged to fix as many bugs as
possible, so that we can be reasonably certain that the 1.4.0 release
does not contain any serious, already-known problems.

> Obviously there are known and unknown bugs in 1.4 as in every piece of
> software, so there it would be unreasonable to release 1.4.0 when it
> is free of known bugs.

I think you mean it would be unreasonable to _wait_... nobody would
complain if we released 1.4.0 free of all known bugs :-)

> On the other hand, the code has undergone some significant changes
> in recent times (new loader, completely new build scheme, the recent
> cli format debate, etc.) so it would be unreasonable for users to
> think that 1.4 has the stability of an even-numbered release.

I don't believe that anyone expects 1.4.0 to be production-ready,
including the development team.

> Given the above, and the relatively small number of active developers,
> one cannot expect me or other developers to have time to work on
> different sets of fixes, one for trunk (with relative freedom on
> new features), one for 1.4 (with the new-feature ban).

I disagree wholeheartedly. If bugs are fixed quickly when they are
found, the divergence between the branches doesn't cause a problem. When
bugs sit without being fixed for weeks/months, and developers move on
with code restructuring, whitespace fixing, etc. (things which do not
fix bugs), then merging the bug fixes into higher branches is harder work.

During the entire 1.4 development cycle, it has been the policy that
bugs get fixed in the 1.2 branch first, then 1.4. This has not caused
anyone undue pain, and very rarely was the fix for 1.4 radically
different than the fix for 1.2. In fact, once 1.4 is released, this will
STILL be the case: bugs get fixed in 1.2 first (if applicable), then
1.4, then trunk.

> With the above in mind, I would suggest the following:
> 
>  - settle on a very short deadline (e.g. 1-2 weeks, really no more)
>    for getting 1.4.0 out, possibly with a notice to users on the
>    "stability" of the release.

That is already the plan. I had hoped to do a beta release yesterday,
but due to other time pressures I am over 150 commit messages behind on
reviewing what has been done in the past few days, and I'm still not
completely comfortable with the changes made to the CLI interface since
the last beta.

>    This would let developers find some motivation to work on critical
>    issues for getting 1.4.0 out.

Really? You think that an artificial deadline will do that? We've tried
twice already, and it had no effect. Critical issues are critical
issues; they aren't less important just because the next release is more
than two weeks away.

>  - lift the 'no new features' ban for 1.4.1, so developers could backport
>    fixes and backward-compatible features from trunk without wasting
>    the extra time to remove the 'new features' part (something that
>    could discourage even trying to backport the fixes);

Sorry, as Russell already responded, this will not happen. New features
don't go into release branches. Fixes should not _NEED_ to be backported
from trunk (see above, they should not go into trunk without going into
the release branch first).

>  - schedule 1.4.1 (or 1.4.2 if you like) for end of january to get
>    a more stable release in this branch.

I suspect it will be no more than 4 weeks after 1.4.0 is released before
we see 1.4.1, and it may be much sooner than that depending on what
problems are found after the release.