<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
I agree that we can change the release cycle to be longer.<br>
Thomas already put the dates for 2.8 into the wiki:<br>
<br>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
Beta version 2010-06-30 feature freeze <br>
Release candidate 2010-07-07 i18n freeze (aka string freeze) <br>
Final release 2010-07-14 <br>
<br>
This is based on the current, 8-week schedule, I believe. I have no
problem with extending that for 2.8, but this schedule would work best
for me, because I will be on vacation after that. So somebody else
would have to do the release. If somebody volunteers, then we can
change the release dates. After 2.8, we can switch to a quarterly
release cycle anyway.<br>
<br>
What's going to be in 2.8 anyway? The
<a class="moz-txt-link-freetext" href="http://devel.bibletime.info/wiki/Development_Plan">http://devel.bibletime.info/wiki/Development_Plan</a> is still very short...<br>
<br>
Regards, mg<br>
<br>
Am 21.05.10 04:22, schrieb Gary Holmlund:
<blockquote cite="mid:4BF5EE76.4060200@gmail.com" type="cite">On
05/20/2010 01:25 PM, Raoul Snyman wrote:
<br>
<blockquote type="cite">Hi guys,
<br>
<br>
With the recent release of BibleTime 2.7, and looking at how short the
<br>
changelog is, I felt that we should review the length of the release
cycle.
<br>
<br>
I know that the reason it was shortened to 6 weeks was so that we would
get
<br>
new versions going out regularly, and without months and months of
inaction,
<br>
but I think that 6 weeks is too short a time to actually get a lot of
work
<br>
done.
<br>
<br>
When there is a new release with a significant version number (like
2.7), I
<br>
would expect some fairly major new features, but recently we've mostly
been
<br>
bug fixing, which should be relegated to a bugfix release number (like
2.6.1),
<br>
since it doesn't have any significant new functionality in it.
<br>
<br>
Certainly from my perspective, and I know from some other folks'
perspectives
<br>
as well (Jaak, for instance), I don't have a lot of time on my hands,
and
<br>
while I'd like to contribute to BT, the 6 week cycle means I don't get
enough
<br>
of a chance to do anything. I sadly haven't even been able to attend
the last
<br>
two *-a-thons.
<br>
<br>
I propose we lengthen the cycle to 3 months, and implement bugfix
releases.
<br>
This way our release cycles are long enough to include new features,
and we
<br>
can still fix up some bugs and release bugfixes.
<br>
<br>
Quite honestly, I think that going up 4 releases in a standard Ubuntu
release
<br>
cycle is a little ridiculous. It's almost like we're pushing up our
version
<br>
number just to look like a really mature project.
<br>
<br>
I'd really like to get stuck into the UI and try to make things better
in
<br>
terms of usability and "pretty", but the current release cycle doesn't
work
<br>
for me :-(
<br>
</blockquote>
We have had a 8 week release cycle with 6 weeks of development time. I
agree it is to short to work on larger features. A 13 week release
cycle with 11 weeks of development would be better.
<br>
<br>
The shorter cycle has been good for getting recent versions into Ubuntu
and Fedora. We need to think about how a 13 week cycle will affect
this. Jonathan says that August 12th is the latest date for getting
into Ubuntu 10.10. I suggest our next release date be August 1st and
then quarterly after that. This should keep us on cycle with Ubuntu
since they have 6 month release cycles. Fedora is also on a 6 month
cycle about 1 month behind Ubuntu. This would mean that would be a 10
week release cycle for the next release.
<br>
<br>
Gary
<br>
<br>
<br>
<br>
<br>
_______________________________________________
<br>
bt-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:bt-devel@crosswire.org">bt-devel@crosswire.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://www.crosswire.org/mailman/listinfo/bt-devel">http://www.crosswire.org/mailman/listinfo/bt-devel</a>
<br>
<br>
</blockquote>
</body>
</html>