On Sun, Aug 14, 2011 at 04:29:40PM +0000, [email protected] wrote: > I know the version numbers as Major.Minor.Patchlevel -- I would think > this would be a candidate for 0.2.1, no?
Yes, that's right, and that's the route that we're now taking. What I was contemplating was something similar to what what a downstream package manager might do: Debian, Apple, FreeBSD, etc. routinely apply patches and make interim releases rather than wait on upstream. Right now, if you get the Apache HTTPD server for Debian Lenny, the package version number is "2.2.9-10+lenny9". It's not the same thing you get if you download Apache HTTPD 2.2.9 from the Apache mirror system. The source tarball that people get when they download Lucy from CPAN is similarly, not the same as the canonical source tarball linked to from <http://incubator.apache.org/lucy/download.html>; CPAN is officially "downstream", like the others -- and the situation will be the same with the archives our future Ruby and Python users will download from RubyGems and PyPI. The CPAN package is already modified and unofficial, and so my understanding is that it can be modified further -- for instance by making a small patch which fixes the current build bug. If we did that, we would be forced to increment the Lucy version number, because the CPAN system does not allow you to upload two different files named "Lucy-0.2.0.tar.gz". However, as we would not want to conflict with a future official Apache Lucy 0.2.1 release, we would do like the Debian people have done and append additional info to the release number beyond X.Y.Z -- hence, "0.2.0.1". However, as the former benevolent dictator of this codebase, I am uniquely unqualified to take us down that path. Lucy's principle remaining challenge is that we continue to rely too heavily upon me. We've made decent progress in that regard, but we need to do better still. It would damage the community if I were to make a unilateral decision to issue a quick fix. Other people need to be stepping up and making these fixes, and other people need to be involved in the decision-making process. Fortunately, we have enough people who are voting on our releases consistently to turn around 0.2.1 as quickly as the Apache voting institutions will let us (72 hours). It's not ideal, though, because we have broken any distros on CPAN that rely on Lucy as a dependency, and they are staying broken while we take our sweet time getting the fix out -- e.g. Peter's Dezi, Search::Prog::Lucy, and so on. In the future, things will be much worse, because Lucy is designed to be a bulletproof low-level library that more sophisticated applications like can be built on top of. It would be most unfortunate if we allow our release process institutions to undermine the reliability of our products and discourage their use. Marvin Humphrey
