[sword-devel] Nearness to release

[Troy A. Griffitts]

Jonathan Marsden wrote:
> Troy A. Griffitts wrote:
> Good :)
> 
> Is there is list of all known release-critical bugs and TODO items
> somewhere?

No, the bugtracker is clean now for critical 1.6.x changes, as far as I 
know (right?).  We're only fixing feedback we get on the RCs now.

The only outstanding issue of which I know is the link bug DM is working 
on with osis2mod, but I'm about to tell him that he probably needs to 
check the ordinal count of his returned ListKey in a different manner in 
our osis2mod utility, so this probably won't be an API change.  I think 
we're just waiting now to bundle locales and v11n systems.  No code 
changes unless someone speaks up about something I've overlooked again.

> There have now been several commits since 1.6.0RC2... (I'd
> say exactly now many, but it wasn't tagged... :)

scribe at scribe-laptop:~/src/sword-1.6.0RC2$ svn log -r {`ls -l 
configure|cut -f6 -d' '`}:HEAD http://crosswire.org/svn/sword/trunk

:)


> is it perhaps time for an RC3 and a freeze on all non-essential changes until we can get a
> final 1.6 "out the door"??

Yeah, I'd say so.  I'm about to head out to evening service at Church 
since I slept in this morning :) and when I get back, if no one has 
complained, we can bundle an RC3 and hopefully go out the door soon.  I 
don't consider locale or v11n data changes warrant for a new RC, so if 
we only get those changes over the next couple days, let's shoot to 
release a final on Tuesday evening PST.

> (Creating a branch for the 1.6.0 release, so that new commits intended
> for 1.6.1 could continue on svn head, would also work well, but that
> doesn't seem to be the "SWORD way" of doing things).

:)  Again, this release has undergone a little more testing than usual 
as we're hoping to 'change our ways' with this BRANCH and force 
ourselves to not do API changes in 1.6.x.

My plan is to continue to work on 1.6.x for a while (months), improving 
speed, filters, and fixing any bugs, and actually USE 1.6.x in some of 
my own apps for a while before starting any API-changing additional 
features which will require a branch of HEAD to 1.6.x, and 1.7.x to 
continue in HEAD at that point.  I don't want to have to branch until we 
necessarily start 1.7.x API-breaking changes; otherwise we have to keep 
merging 1.6.x changes into HEAD, which would make the lines identical 
till we start 1.7.x work anyway.  Though we will definitely TAG 1.6.0 
(which is the same as a branch anyway in svn-- if we need to change our 
minds for some odd reason).

How's that for a plan?

	-Troy.