[bt-devel] Reviewing the Release Cycle

[Martin Gruner]

Hi,

I agree that we can change the release cycle to be longer.
Thomas already put the dates for 2.8 into the wiki:

Beta version 2010-06-30 feature freeze
Release candidate 2010-07-07 i18n freeze (aka string freeze)
Final release 2010-07-14

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.

What's going to be in 2.8 anyway? The
http://devel.bibletime.info/wiki/Development_Plan is still very short...

Regards, mg

Am 21.05.10 04:22, schrieb Gary Holmlund:
> On 05/20/2010 01:25 PM, Raoul Snyman wrote:
>> Hi guys,
>>
>> With the recent release of BibleTime 2.7, and looking at how short the
>> changelog is, I felt that we should review the length of the release
>> cycle.
>>
>> I know that the reason it was shortened to 6 weeks was so that we
>> would get
>> new versions going out regularly, and without months and months of
>> inaction,
>> but I think that 6 weeks is too short a time to actually get a lot of
>> work
>> done.
>>
>> When there is a new release with a significant version number (like
>> 2.7), I
>> would expect some fairly major new features, but recently we've
>> mostly been
>> bug fixing, which should be relegated to a bugfix release number
>> (like 2.6.1),
>> since it doesn't have any significant new functionality in it.
>>
>> Certainly from my perspective, and I know from some other folks'
>> perspectives
>> as well (Jaak, for instance), I don't have a lot of time on my hands,
>> and
>> while I'd like to contribute to BT, the 6 week cycle means I don't
>> get enough
>> of a chance to do anything. I sadly haven't even been able to attend
>> the last
>> two *-a-thons.
>>
>> I propose we lengthen the cycle to 3 months, and implement bugfix
>> releases.
>> This way our release cycles are long enough to include new features,
>> and we
>> can still fix up some bugs and release bugfixes.
>>
>> Quite honestly, I think that going up 4 releases in a standard Ubuntu
>> release
>> cycle is a little ridiculous. It's almost like we're pushing up our
>> version
>> number just to look like a really mature project.
>>
>> I'd really like to get stuck into the UI and try to make things
>> better in
>> terms of usability and "pretty", but the current release cycle
>> doesn't work
>> for me :-(
>>    
> 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.
>
> 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.
>
> Gary
>
>
>
>
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/bt-devel/attachments/20100527/cbcd3d5c/attachment.html>