On Mon, Mar 16, 2009 at 11:38 AM, Matthew Talbert <[email protected]> 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: [email protected] > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page > _______________________________________________ sword-devel mailing list: [email protected] http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
