Skip to Content.
Sympa Menu

freetds - Re: [freetds] release protocol

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddyz77 AT tin.it>
  • To: FreeTDS <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] release protocol
  • Date: 14 Jan 2003 08:03:25 +0100

Il mar, 2003-01-14 alle 06:23, James K. Lowden ha scritto:
> I want to solicit advice for how to release 0.61. We've been saying it's
> about time, and currently there's only one TODO:
>
> Broken:
> . tds_connect free tds structure on failure. This cause in some condition
> a pointer to garbage in some library
>

Opps... I discovered this problem time ago but I forgot to send a mail
to ML. This problem is also a 0.60 problem. tds_connect has changed many
time. In 0.53 it allocate and return TDSSOCKET structure and return NULL
(deallocating structure) on failure. Now a TDSSOCKET* structure is
passed to tds_connect, but tds_connect still delete this structure.
Some library retain the TDSSOCKET pointer for later use but this now
point to garbage... Try to grab a week ago snapshot and make a failure
connect with CTLib... it core trying to free garbage. I commit a fix but
I don't like that much.
IMHO the clearest method it to leave called delete TDSSOCKET* structure
and change tds_connect according. Faster fix is to clear saved pointer
if tds_connect fail.

> I don't know if this is correct, or whether we want to fix it before
> releasing.
>

This can cause core, so is good to fix all these problems.

> But that's not the real question. The real question is, what should be
> the steps to prepare for a release. Questions:
>
> 1. How widely should .pre and .rc candidates be distributed?
> 2. How widely should they be announced?
> 3. How do we know when to call an rc 0.61?
> 4. How should the .pre/.rc status be reflected in AM_INIT_AUTOMAKE?
> 5. How to deal with CVS? Branch now, applying tags for each pre/rc? Or
> tag now, and branch only when we reach a pretty good rc, or something
> else? (Branch now seems simple, but might mean more pull ups?)
>
> I'm prepared to copy almost any nightly snapshot and call it pre1.
>
> I'd also welcome other suggestion and such. I'm not an experienced
> release engineer. Well, not *much* experienced, at any rate.

I think there aren't role.
1,2) I think they should be released widely as possible for removing all bugs
we found before release.
I don't think we test on IRIX, AIX, HP/UX, nor we use all DBD::Sybase, PHP,
and other tools...
3) Well, next prerelease will be 0.61rc1 or 0.61pre1 and configure.in should
be updated with 0.61 version.
4) I don't know. Previour release do not change that...
5) We never branched. You can tag for every pre/rc release. The release tag
is a must.

The problem with branch is that you should mantain the branch. If you want
all developer start adding all the features you want we have to branch and do
fixes in that branch while MAIN branch can be improved separately.
It depend if you want to pause adding features or not.

freddy77






Archive powered by MHonArc 2.6.24.

Top of Page