On Mar 11, 2006, at 11:51 AM, Paul DuBois wrote:
> Hi, I have a few questions about "how things are
done" for this
> project:
There really isn't any official anything for this project,
but maybe
your questions below are a good place for us to start
thinking about
policies?
> Since I last updated my Ruby DBI article
> (http://www.kitebird
.com/articles/), a few things have changed,
> such as that
> the project now is on RubyForge rather than
SourceForge. I should
> update
> the article again to reflect that. I'd also like to
include
> something about
> using the DSN options for MySQL to specify how to
access the
> contents of
> MySQL option files, and how to get the SQLSTATE value
from exception
> objects. However, the changes for these capabilities
currently
> exist only
> in the CVS. Question: What is the procedure for
requesting that
> there be a
> new Ruby DBI release, so that these changes become
available
> "officially"?
There really isn't any procedure. Personally, on my own
projects I
like to do a release once a month or so, as long as there
has been a
new feature added or a bug fixed. Looks we're creeping up
on that
month just about now, and it looks like you did add those
MySQL
features. So I would be fine with releasing 0.1.1 soon,
though I'm
also interested in hearing other people's opinions.
> I made a couple of changes to the top-level README,
which becomes
> the page
> seen at http://ruby-dbi.rubyf
orge.org/. (For example, I added links
> to the
> main project page, http://rubyfo
rge.org/projects/ruby-dbi/, and to the
> downloads page.) Question: What is the procedure for
updating
> http://ruby-dbi.rubyfo
rge.org/ so that it includes changes to README?
Also no procedure. Our documentation process in general is
fairly
slight now. But the README file can be published (via RDoc)
using the
"docs" task in the Rakefile. I'm not totally
crazy with the way it's
setup right now; for one thing, I tried to make things
prettier
before releasing 0.1.0, and the idea of pushing nice
formatting
through RDoc just started to bug me. Maybe eventually we'll
want to
do this through something fuller, like (ahem) Docbook.
But to answer the nuts-and-bolts part of your question:
1. Edit the README.
2. Run "rake docs", which will publish changes
in the README to doc/
html/index.html.
3. cvs commit the changes.
4. SCP the new index.html file to the Rubyforge site.
> Question: Is there some preferred place within the
project
> repository where
> I should actually _document_ how changes such as the
new MySQL DSN
> options
> work?  The
changelog has entries for thse, but that doesn't
> seem the
> proper place for general documentation. And I guess
the DBD_SPEC
> file isn't
> necessarily the right place, either.
Yeah, good question, also relating to documentation. Maybe
we should
be figuring out how to API RDoc, and then if we had RDoc for
each
DBD, we could have DBD-specific info there?
Francis Hwang
http://fhwang.net/
_______________________________________________
Ruby-dbi-next mailing list
Ruby-dbi-next rubyforge.org
h
ttp://rubyforge.org/mailman/listinfo/ruby-dbi-next
|