[bt-devel] Development after 1.7

[Jonathan Morgan]

On Thu, Feb 12, 2009 at 3:19 AM, Eeli Kaikkonen
<eekaikko at mail.student.oulu.fi> wrote:
> Quoting Gary Holmlund <gary.holmlund at gmail.com>:
>
>> Martin Gruner wrote:
>>>
>>> Hi BibleTime team.
>>>
>>>
>>> Now it is time to think about how we should continue to work  together in
>>> this project. Let me share my - personal - thoughts,  and let us then
>>> discuss.
>>>
>>>
>>> First of all, we need to CHANGE our development policy radically.  Two
>>> years to create a new version of a software is by far too much!
>
> I can't disagree with that :)
>
>>> RELEASE OFTEN must be our guiding principle. With a quick release  cycle
>>> it is also easier to iron out mistakes that should have crept  into a
>>> release.
>>> IMO we should have a release per one or two months, ideally, more  often
>>> is possible if there are many contributions. That means that  each release
>>> does not have a "brand new" version of BibleTime, but  some new features and
>>> some bugfixes. The rest of my thoughts flow  from this principle, and I'd
>>> like to hear if you can accept this  new approach. It is the most important
>>> point for me.
>>>
>
> It's a good principle. It would be very nice if we could give something new
> in the UI with each release, whether it be a better layout or a perceivable
> speed improvement.

Release often is a great idea.  It's a real pity that neither Sword
nor BPBible does it, but I wish you success.

>>> Planning should take place in
>>>  http://devel.bibletime.info/wiki/Development_Plan. We create a  feature and
>>> bug stack, and decide which items will be tackled for  the next release.
>>> Others will be postponed to the next or a later  version.
>
> We have used this already with success, but lately it wasn't updated often.
> It's a good tool, we just need to use it in some predescribed manner.
>
>>> Our source code repository (SVN TRUNK) should *ALWAYS* be in a near-
>>> releaseable state. That means that everything checked in has to  compile
>>> and not break the application to be unusable.
>>> Larger changes can be done in a development branch (for  cooperation) or
>>> a local checkout of a developer and have to be  merged back to TRUNK if they
>>> are ready to be tested. That is the  responsibility of the developer(s)
>>> working on these changes.
>
> Sounds good enough. We just have to learn how to use svn more efficiently. I
> have not abandoned the idea of distributed version control, but the time is
> not yet right for changing that. If we get more developers this may be
> topical within one or two years. Meanwhile, read e.g.
> http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
>
>>>
>>> This is (the attempt to realize) the approach of "agile software
>>>  development". See
>>>  http://www.pragprog.com/titles/pad/practices-of-an-agile-developer  if you
>>> want to know more about it.
>>>
>
> Agile development is a hot topic in industry. It may be very useful.

Which is why you have to define reasonably carefully what you mean by
agile development, since it can now mean almost anything.  One project
I worked on last year used an "agile" approach characterised by
http://img111.imageshack.us/img111/1776/dilbert2666700071126ni1.gif,
and it is not at all uncommon to do this (not saying Bibletime will,
just that it pays to be careful).

Jon