[sword-devel] [sword-support] deuterocanonical support

[Greg Hellings]

On Mon, Mar 16, 2009 at 11:38 AM, Matthew Talbert <ransom1982 at gmail.com> wrote:
>>
>> As far as our version scheme, we used to follow linux kernel version
>> standards of having x.y.z, even y as stable and odd as development.  As the
>> linux kernel no longer does this, I supposed we still follow linux kernel
>> versioning scheme :)  We should have a plan again soon.  We actually had a
>> roadmap to 2.0 in Jira with versioning standardized again.  Perhaps we
>> should relook at this.  But really, how big of a deal is it?  What real
>> world difference does it make if we call it 1.5.12 or 1.6.0?  It hasn't made
>> much difference for the linux kernel.  In principal, of course I agree we
>> should try to make our version system say more than just 'it's easy to see
>> this version is newer than that, but that's about it'.
>>
>
> It makes a lot of difference to packagers, and a few of them have
> asked on this list previously about it with little to no response. In
> general, packagers expect that point releases will not break API *or*
> ABI compatibility.
>
> As it's quite easy to comply with that understanding, is there any
> reason not to? (Assuming of course, that SWORD cares about PR things
> like getting into distros.)

Precisely - if we haven't had a release versioning scheme in place for
9+ years now, why not start again with this current release issue?  A
model like:
Major version - revolutionary changes
Minor version - evolutionary changes (to borrow Chris' phrases)
Sub-minor version - reliability/stability/bug fixes along with things
like filter updates and additions.

Yeah, this would make branching in the SVN something necessary.  But
it seems that if development proceeded apace in the trunk, anything
that was just a sub-minor release point that was also discovered in
the branched version could rather easily be pulled out into a discrete
patch, applied to the branch, and submitted into SVN that way.

Provided the commits to trunk are sensible SVN commits where one
logical set of changes per commit are made, and new releases from
trunk are made semi-frequently, the scheme allows rapid release of
x.y.z versions, maybe even more frequently than 6 months, whenever
there is a bug that is fixed, while development of x.y can continue
apace and be delayed, like the current trunk has been, so that no one
need wait for many other front ends to catch up with the evolutionary
changes just so they can release against a version that fixes the
filters or a minor bug that appeared in their release cycle.

I don't see this as requiring an entirely separate individual, if the
purpose of the minor/sub-minor is restricted to just time between the
minor-version releases.  There would be no need to maintain, say, the
1.x.y series beyond the time of the release of 1.(x+1), and a proper
use of patching should allow quick back-porting of the issues to the
1.x series for a bug that was fixed in head.

OK, so it might be too late to salvage the changes from 1.5.11 to HEAD
with a branch, but once the next version with v11n is released,
calling it 1.6, creating a branch, and continuing with development of
new features for 1.7 while doing the backports to 1.6 for bug-fix only
seems perfectly logical to me.  It then makes the version numbers from
here on out meaningful.  Mainly that 1.5 is KJV-only, 1.6 is v11n, 1.7
is full GenBook Bibles, 1.8 is... and so on.  And 1.6.1 is a faster
version of v11n while 1.6.2 solves a crash as well as a rendering bug,
etc -- in short that 1.6.x fixes 1.6.(x-1) while 1.7 adds new features
and might break the API or ABI.

--Greg

>
> Matthew
>
> _______________________________________________
> 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
>