Am 27.11.2008 um 00:11 schrieb Jonathan Morgan:
> On Thu, Nov 27, 2008 at 9:22 AM, Troy A. Griffitts <[EMAIL PROTECTED]
> > wrote:
>>> Isn't this kept in SWVersion.currentVersion? Backward
>>> compatibility is
>>> removed every new SWORD version, I think (not on purpose
>>> necesarily, but
>>> there are always some things to fix.
>>
>> I don't believe this is true. Although we add new features,
>> sometimes
>> changing object sizes-- which may prevent binary compatibility, not
>> sure-- we try hard to maintain compile compatibility. I would think
>> that most old versions of frontends could compile on 1.5.11. TRUNK
>> is
>> an exception because of the underlying requirement of dyn
>> versification
>> (dv11n) to not provide a static array of book name, chapter, verses
>> any
>> longer. We should probably call this 1.6.0.
>
> Obviously I'm talking from the perspective of someone who doesn't have
> to do it, but I think the following release structure should be
> considered:
> 1. Minor bugfixes / efficiency improvements lead to near immediate
> minor point releases (e.g. if the efficiency changes made some months
> ago for compressed modules had been made while Sword 2.0 was the
> current release, then it would be released as 2.0.1).
>
> 2. New filters also be released as new minor point releases when they
> are implemented (I don't like the number of times we have a new module
> that works but has to sit in beta waiting for a new release and then
> new releases of different frontends - e.g. if there were Ruby filters
> implemented when 2.0.2 was current, then a new version with just those
> filters added could be 2.0.3, and the modules could depend on 2.0.3).
>
> 3. More major changes (don't know how we define this, but breaking API
> and six monthly releases are probably good starts) become major point
> releases (e.g. 2.0 -> 2.1).
>
> If possible, we should try to maintain ABI compatibility for minor
> point releases ((1) should, I'm not so sure about (2) - the above link
> goes into detail about all the things that can break ABI for C++). If
> we can do that, then the library could be packaged under Linux as
> libsword2.0.so.{0,1,2,...}, and thus new filters and bugfixes could
> easily get to fontends without requiring their packages to be rebuilt
> (on Windows we would probably still have to rebuild binaries, but
> anyway...)
I think that's a good plan.
Manfred
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
