Skip to Content.
Sympa Menu

freetds - Re: [freetds] Need for 0.83 as stable version

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Need for 0.83 as stable version
  • Date: Mon, 8 Jun 2009 22:48:40 -0400

Sebastien FLAESCH wrote:
>
> I believe what I am suggesting here is to keep 0.83 as stable as
> possible, and not make major (risky) changes in this version, and if
> possible provide what so called "Maintenance Releases", from time to
> time, fixing blocking bugs...

Hi Sebastien,

I am glad you mention all that because it helps me understand your
situation, which I'm sure others share. At the same time, I don't see
myself spending time to make more frequent releases. Brian used to say
he'd issue a new release when he got tired of answering questions with,
"it's fixed in CVS". I feel the same way: form follows function. The
release schedule is determined by the developers.

Your firm has two things the FreeTDS project does not:

1. Customers
2. Revenue

Those things give you problems we don't have and resources to address
them. There are a few ways you might do that:

1. Directly contribute to the effort
2. Maintain your own tree, a la Red Hat & Fedora
3. Money

(Mind, I'm not asking for money and wouldn't accept it. But someone else
might, and I don't question the motives of people who contribute to the
project. The idea of holding releases for ransom is mildly amusing,
though.)

As for riskiness, I've learned a few things. I don't upgrade Autoconf &
friends just before or just after a release. And we generally don't
change libtds near a release either, because it can affect the "other"
API, the one you weren't focussed on.

> As long as and commit comes with a regression test, and if that commit
> does not break existing tests, I would release more often...

But we have no such thing. The unit tests are better than nothing, but
they're far from exhaustive. And there's the problem of testing on
systems one doesn't have: 32/64 bit, DM versions, Perl/PHP versions,
operating systems. The real feedback mechanism is right here: people
trying things and reporting what doesn't work. (As you know yourself!)

Releasing is work. Bad releases are a lot of work, on both sides: they
spawn a lot of questions and problems on the list, and force quick
follow-on point releases until things settle down. None of which serves
anyone well. After you've been through that once, you get conservative.

Regards,

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page