[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Copyright zzzz



Lars Hellstrom:

> To clarify things: My reluctance is towards a complete maintenance
> responsibility (since that would mean I have to figure out what the
> !@%&#!@# the !@%*&#!@# \latinfamily !@%&#!@# command #!@#!@%& does
> and also fix the !@%&#!@# thing from time to time). I would rather
> prefer to share it with a few other people.

OK, I'm fine with the idea of a shared maintenance, as long as this
doesn't interfere with Alan's ideas about putting fontinst under a
licence which doesn't allow anybody else but him to put out the next
"official" version under the original name.

As far as shared maintenance goes, I don't mind taking care of the
\latinfamily stuff, since it was my impression that it was mostly
stable anyway.  Most of the changes will probably relate to fixing
low-level commands, such as dealing with real numbers in AFM files.

> I have been working on a new version during the last month but I
> have a few other things to take care of first, so it will probably
> take another month at least before I am finished. Furthermore, what
> I have been making changes in is fontinst.dtx itself, so someone
> should try to do something about some of the other files as well
> (perhaps mainly the manual).

Is it feasible to break fontinst.dtx into several modules that could
maintained more easily by different maintainers?

> What would, to me, seem like a reasonable idea is to do the
> following: Create a new directory in the CTAN/.../fontinst; call it
> "new", "beta", "prerelease", or something like that. In this
> directory we (the fontinst manitainers community) construct the new
> hierarchy of files that will constitute the next fontinst release,
> uploading the individual files as they are completed.  Then when we
> decide the new release is completed, we let it replace the current
> one (and then probably start all over again, as soon as someone gets
> an idea for an additional improvement).

> I do not know whether the organisatorial structure of the CTAN
> archive would allow such a construction, but it would have a number
> of advantages.  Firstly, new features (such as using AFMs with real
> dimensions, which will be included in the version I am working on)
> can quickly become available to the more advanced fontinst users
> that can figure out how to use it without an explicit manual
> (perhaps this one doesn't require any manual, but other new features
> do). Secondly, this means that there will be some beta-testing of
> fontinst going on, with all the usual advantages of that. Finally,
> all this is achieved without making the previous well-documented (at
> least as of v1.8, and hopefully in the future too) and well-tested
> version unavailable to new users that would really need an easy
> start.

> Any opinions on that?

I agree that it might be a good idea to prepare a test version first
before replaincing the last stable version, but I doubt that CTAN is
the right place for that.  (BTW, what about a fontinst homepage on
www.tug.org?)

> There is, by the way, another thing I've meant to write and ask
> about. Is there any convention regarding the exact meanings of the
> words "version" and "release"? What made me worder is that the v1.8
> fontinst.dtx contains the two sections

>        About this version of \texttt{fontinst}
> and
>        About this \texttt{fontinst} release

> which to me seem to have exactly the same meaning! 

Good question.  I don't think there was any deeper reason behind it.

> I've been considering the possibility that a version change
> constitues a minor update (say, in units of 0.001) while a new
> release constitutes a major ditto (say, in units of 0.1), but as the
> respective contents of the two sections didn't seem to provide much
> support to that hypothesis, I though I'd better ask (which I have
> now done).

I'd consider version and release more or less as synonyms, so I'd just
distinguish between major (0.1) and minor (0.001) versions/releases.
Obviously, introducing new features should be a good reason for a major
update, whereas bug fixes are usually just a minor update.

Hope this clarifies it.

Cheers, Ulrik.