[bt-devel] BibleTime 2.0.alpha2 is released

[Jonathan Marsden]

Eeli Kaikkonen wrote:

>>  * A public beta test period in which some defined number of users run
>> the beta for a defined amount of test time within a given period, and
>> report their results (example beta test definition: 20 different users
>> will test the BibleTime 2.0 beta1 release, each user will install the
>> product and use it for at least 30 minutes between 01 April 2009 and 15
>> April 2009; at least 15 of these users will report their use by email to
>> bt-devel, including reports of any bugs or issues found).

> Very good, but considering the realities we have seen, this will never
> happen. People just don't report enough - I don't know whether there are
> people using it or not.

What can be done to change that?  Offer something BT users might want,
in exchange for doing some testing and reporting that you did so?  Such
as an unlock key for a normally-non-gratis SWORD module, maybe??  I'm no
marketing person, but "release early, release often" is really only
valuable if it gets you feedback from the user community.  So if there
is a real issue here for BT, those on the team with a more "marketing"
mindset might want to get creative about how to increase feedback from
users of test releases.

>>  * Check all known bugs for any showstoppers (either known now or
>> arising from beta testing).  For example, is the rather odd look of the
>> themes other than the default one (simple) considered a showstopper for
>> a final release?  This issue is still present on my machine here running
>> BT 2.0 alpha2.

> I think this is release critical.

Good (I think so too)!  Is there a way to mark all "release critical"
issues in a bug tracker so that it is easy to get a list of them?  If
not, should there be a way to do that? :)

>>  * Create and test installers for all available platforms (including
>> Windows, if 2.0 is to be a Windows-capable release).  Is anyone building
>>  and testing under OS X using Qt/Mac yet? :)

> We shouldn't release a 2.0 final for Windows if there is no good
> installer. Whether it prevents us from releasing 2.0 altogether is
> another matter.

OK, fair enough.  My sense was that the main reason for calling it 2.0
at all was the new portability to Windows that migration from KDE to Qt
offers.  If that is correct, then releasing 2.0 for Linux (and Mac?)
only would feel a bit odd.  If there are other things (new features?) in
2.0 that make it seem worthwhile to end users to be released as 2.0,
then sure, we could decide not to release on Windows until 2.1 or whatever.

>> Lastly, it's a bit debatable to call this a release requirement, but I'd
>> also suggest that it would be very much preferable if the code was known
>> to build correctly under Windows using a free (libre) toolchain.  ...

> It can't be a requirement unless someone succeeds in it. I just got a
> Windows XP laptop and am going to install VS Express.

Well, it could conceivably be a requirement for a Windows release.  In
that case, no-one having succeeded would cause a delay of releasing BT
on that platform until someone does succeed :)  Whether that delays the
whole 2.0 release then relates back to the "is BT 2.0 really all about
Windows portability?" way of thinking that I mentioned earlier.

Personally, I'm still resisting the lure of any closed proprietary tools
for the development stuff I do outside of paid work, which includes BT...

It sounded to me from earlier discussion as though someone (Gary? Greg?
I forget!) had got pretty close to a working MinGW development setup,
other than some issues with CLucene headers.  If that development setip
can be documented so it can be reproduced, I'll make time to look at it
further.  Not that I think I'll necessarily do any better than you guys
with it... but I can try!

> From now on we should start using the wiki "development plan" pages
> effectively. Now it has happened that Gary and I have been working on a
> same feature and half of the work has been futile. Please, Gary and
> others, edit the plan page (and the windows build page). Write there if
> you take some task or if you have some new task. Jonathan and other
> non-core-developers can add tasks, too. We will move or remove them if
> necessary.
> 
> I just renamed the "Next release" section to pertain to alpha3. Whenever
>  a new release is out or we change plans, we can change it. Let's take
> there all TODOs which need to be considered before the 2.0 final. You
> can add also links to the SourceForge bug database.

Sounds good to me. I'll add a new subsection 1.1.9 to
http://devel.bibletime.info/wiki/Development_Plan for Release Critical
Bugs, and start populating it from the SF bug tracker.

Jonathan