Re: public releases

[Guido Draheim]

Peter Simons schrieb:
> Guido Draheim writes:
>
>  > [Public releases are] actually a form of communication to
>  > maintainers of local copies (i.e. "administrators") that now is a
>  > good time to sync the official part of the autoconf extension
>  > repository.
>
> How often should we "release"? By what criteria? I can think of the
> following options:
>
>  (1) We release every time a new macro has been accepted into the
>      archive.
>
>  (1a) If we have several candidates pending that look good, we might
>      delay the release a couple of days to include all of them in a
>      batch.)
>
>  (2) We release in time intervals. (Weekly? Biweekly? Monthly?)
>
>  (3) We release whenever we want to.

given my experience (sorry to throw that up here :-)=)), it is a
combination of all of these, with stressing (3)+(1a). When there
are minor updates or simple macros then it is generally not
worth it to go through a release cycle - which would include
packaging, testing of the local installation, and announcement
in various places like freshmeat. Sometimes a single macro is
so much interesting, it ought to be rolled out as a release
block pretty soon, at most a few weeks later. Even with small
updates, a release should be rolled sometimes, perhaps a few
more weeks later (which could amount to months later). The
real world however shows, that macros/updates are not sent in
constant flow - instead we see them roll in as some bunch of
macros at a time, strongly correlated to holiday seasons. It
turns out that about 3-6 releases per year is sufficient and
appropriate. And actually - no administrator would like it
to be harrassed every week with some update, so this human
factor limits the range at 1-8 releases per year anyway. And
about that one, there is certainly some intuition among
the maintainers when is a good time to do some release cycle.


>  > [Release version numbers need only be incremental] to fullfil the
>  > need of the usual package formats.
>
> Should we provide version numbers at all? Or wouldn't it be better to
> date-stamp the releases as in:
>
>     autoconf-archive-2003-01.tar.gz   (January 2003)
>     autoconf-archive-2003-02.tar.gz   (February 2003)
>     [...]
>
> Plus:
>
>     autoconf-archive-current.tar.gz
>
> Which is updated immediately when the archive changes in any way.

oops. You are right. Since release cycles are improbable to
occur more than one per month anyway, well, let's make it
with year-and-month-number. That's strictly incremental
for sure :-)

> If we want to provide conventional version-number-ing, what policy do
> we use as when to increment the major version number and as when to
> increment the minor version number?
>
> Thinking freely, the following possibilities come to my mind:
>
>  (1) Increase the major version every time the structure changes.
>      (Like categories being added.) If else, increase the minor version
>      number.
>
>      This means that we could end up distributing an archive having
>      the version "1.1239024". :-)

That might be a valid argument. However, I do not see a real existing
case where it would be a problem to have another category around or
to shuffle macros between categories.

Actual, structure changes should be bound more to the packaging
format, and not the repository in itself. That's like moving a
local copy of the html docs from one place to another or some
such.

In effect - version numbers are great with three parts, a major,
a minor, and a (patch)level. A mapping can be given when two
parts are derived from date numbers - proposing
   6.2003.05 = <generation>.<year>.<month>


:-))