[bt-devel] Development after 2.0 final

Martin Gruner mg.pub at gmx.net
Thu May 21 02:53:17 MST 2009


Hi all,

the release of BibleTime 2.0 final is close. This is the time to thank 
everybody who contributed! BibleTime is starting to become a team effort.

This is also the time to think about how we should continue to develop 
BibleTime in the coming months and years. I have some ideas to discuss with 
you.

RELEASE POLICY

-We already agreed on a shorter release cyle. Now that the major library 
transitions are over, this should be a real possibility, and we should try to 
achieve this goal. A release every 1-2 months would be great, for users AND 
for developers. This also implies that we need to have shorter beta/rc phases.

-Can we talk about a "fixed" timeframe for each release? Maybe like the linux 
kernel team handles it. We could have a 4-week feature merge window, and then 
a 2 week beta and rc phase followed by a release. That way we'd have a release 
every 1.5 months, even if there are only "minor" changes because people had 
less time than usual. I think this would be beneficial. Frequent releases are 
more important than "complete" releases, and they will increase the quality. 
Of course, deadlines can be delayed if there are important reasons.

-Bugfix releases can be made at any time by branching from the tag of the last 
released version and including critical bugfixes there. This is also what I 
plan for 2.0. That means that SVN HEAD is open right after the release again, 
allowing developers to implement/merge new features immediately.

What do y'all think? Anybody against a fixed schedule?

FEATURES

For the next cycle, I'd like to hear what features you'd like to implement. 
Troy and Eeli already spoke about the "auto discovery feature" in InstallMgr 
which we should try to include. What else?

I have these items on my list:
* Require Sword 1.6.0 and throw away code for older versions.
* Require QT 4.5 (this will allow to remove boost)
* Remove boost dependency (patch is already available that does this).
* Require CMake 2.6 (some policies changed in 2.6)

For 2.1, the next version, I think it would be ok to change these 
requirements. Do you agree?

mg



More information about the bt-devel mailing list