[sword-devel] Sword 1.6.2 NOW!
greg.hellings at gmail.com
Tue Sep 14 17:55:58 MST 2010
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
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.
> 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
>>> First, this wasn't exactly a bug fix. It was a workaround for a bug in
>>> 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
>>> 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
>>> 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
>>> 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
>> 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?
>> sword-devel mailing list: sword-devel at crosswire.org
>> Instructions to unsubscribe/change your settings at above page
> sword-devel mailing list: sword-devel at crosswire.org
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel