incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Re: [lucy-dev] Filepath build glitch in 0.2.0
Date Wed, 17 Aug 2011 05:56:53 GMT
On Sun, Aug 14, 2011 at 04:29:40PM +0000, bch@methodlogic.net 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


Mime
View raw message