[sword-devel] Sword 1.6.2 NOW!

[Greg Hellings]

On Tue, Sep 14, 2010 at 1:46 PM, Troy A. Griffitts <scribe at crosswire.org> wrote:
>  Thanks for the email link Greg.  Yeah, the submitted changes in question
> from project A were filter updates, and we do specifically state in that
> email that filter updates are allowed in a stable branch.  It was kindof an
> odd situation.  The updates merely added css classes to a few of the html
> tags which are outputted from the filters, none of the projects involved
> thought adding css classes would break anyone.

Huh, I can understand why!  (btw - is it anything that broke
Bibletime? I haven't heard of these breakages, so I would guess not)

>
> One of the things in head currently which isn't mentioned in that email is
> binding improvements and also your additional cmake make system.  I'm not
> sure how I feel about binding improvements being included in a stable
> branch, but I don't see an issue including an additional make system.  Any
> thoughts?

IMO, it would be the other way.  If people see a CMake system they
will probably think it's exactly like the autotools, which is not easy
to guarantee.  I would think CMake should be held off for a feature
update release and the bindings fixes should be included.  My
alterations in the bindings directory aren't adding new functionality
- it's fixes for functionality which was there but long broken.  I
would hesitate to include those changes though, until we've heard from
the BPBible team.  I've asked a few times since I made the changes and
haven't seen any comments from them on here.  Either they don't use
SVN HEAD in their development, or they haven't noticed any breakage.

--Greg

>
> Troy
>
> On 9/14/2010 6:49 PM, Greg Hellings wrote:
>>
>> On Tue, Sep 14, 2010 at 12:43 PM, Troy A. Griffitts
>> <scribe at crosswire.org>  wrote:
>>>
>>>  Understood going forward.
>>>
>>> There were a few factors which made this a slightly non-standard
>>> situation.
>>>  First, this wasn't exactly a bug fix.  It was a workaround for a bug in
>>> a
>>> version of libcurl.  I was hoping libcurl would be patched.  And no, I
>>> personally didn't report the issue to the curl team, which I should have.
>>>  Secondly, one of our frontend projects submitted a small update which
>>> changed something another of our frontends depended on.  The second
>>> project
>>> had updated their code to still work with the new change, but they hadn't
>>> released yet.  If they had released then everyone would be happy with us
>>> releasing SVN as is.  As it stands right now 1 of the 2 projects will
>>> need
>>> to patch SVN for their frontend to work.  So delaying was a hopeful but
>>> unfruitful exercise.  It was a choice we made to with the best
>>> information
>>> we had at the time.
>>
>> Not knowing the nature of the changes, etc, I don't mean to provide
>> this as a comment on that, but I'd just like to bring back up this
>> email:
>>
>> http://www.crosswire.org/pipermail/sword-devel/2009-June/032108.html
>>
>> and see if that's still the plan?  If you're actually changing how
>> things are working inside (in the sense of enhancing for new modules
>> and content like the NASB and not just for fixing bugs), then maybe it
>> is time to branch and allow for bug fixing/feature branches to develop
>> separately until 1.7 is made?
>>
>> --Greg
>>
>> _______________________________________________
>> sword-devel mailing list: sword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>