[bt-devel] Compatibility break: Sword 1.6RC1->RC2 API change

[Troy A. Griffitts]

Thanks for the support and I understand the criticisms.  Let me just say 
that the one difference here is that we are talking about a 1.6.x BRANCH 
in which NO API changes can be made once it happens.  It is this point 
that is weighing heavier on the decision to make the change right now 
before the branch.  Honestly, I'd rather have the interface where I want 
it right now over stability (obviously I'd like both).  Once 1.6.x is 
branched, I have no problems releasing monthly if we feel the need, but 
it will likely be another year before we branch again and get interface 
changes out in the wild.  Hope this helps explain the decision.

	-Troy.



Jonathan Morgan wrote:
> On Fri, Apr 24, 2009 at 12:33 PM, Jonathan Marsden <jmarsden at fastmail.fm> wrote:
>> Eeli Kaikkonen wrote:
>>
>>> Eeli Kaikkonen wrote:
>>>> Troy changed the Sword InstMgr API between RC1 and RC2.
>> Which I just discovered, trying to package BibleTime 2.0 beta1 with the
>> RC2 libraries installed!
>>
>> Intuitively, this feels like a poor moment to make an API change.  RC
>> means Release Candidate.  If the SWORD API was considered good enough to
>> release at the time of releasing RC1, then by definition it was still
>> good enough for RC2 (or else the fix was for a major security problem or
>> something like that, which absolutely *required* an API change to fix --
>> not the case here, AFAICS).
> 
> What it means is nothing more or less than that you use RC to mean a
> different thing from how it is being used.  RC1 was the first release
> to the wider development community after some reasonably major
> internal changes had been made.  I'm sure Troy wanted and believed it
> to have the stability of a release candidate, but since major
> frontends had not been tested with it at all and it changed the API
> for things like InstallMgr, it is hardly surprising that things might
> need to change.  Considering what it actually was rather than what it
> was called, first alpha or first beta is a much more reasonable
> description.
> 
> Jon
> 
> _______________________________________________
> bt-devel mailing list
> bt-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/bt-devel