Re: proposed numbering and release changes

Duane Wessels wrote:

> Now, given a scheme like that, the numbering gets pretty long. So I
> also thought about maybe dropping the third number and incrementing
> the second number more often. So it would be
>
> 1.3.PRE
> 1.3.REL
> 1.3.P1
> ...
> 1.4.PRE
> 1.4.REL
> 1.4.P1
> ...

OK with me. Perhaps you should have numbering of PRE releases as well.

  1.3.PRE1
  1.3.PRE2 first bugfix before release
  ... if REL gets delayed for any reason, like more bugfixes
  1.3.REL when the latest PRE has been stable for a week (only
spelling corrections allowed).
  1.3.P1 first patch set.
  ...

I would prefer if you made PRE releases more often, like when there is
new version that runs.

Between different versions of 1.3.X there should ONLY be bugfixes. New
features should always require a new version number.

At times when development rate is high, it may well be that no REL
version is made since a version never gets classified as stable before
the next version is.
    Features frosen into a 1.3.PRE1 version
    Some bugfixes before release 1.3.PRE2
    New features added, starting a new version 1.4.PRE1
    More bugfixes 1.4.PRE2 (and perhaps 1.3.PRE3)
    1.4 gets classified as stable. No need for a stable 1.3 release.

To get the most out of this versioning it is important that bugfixes are
always made on the last REL release and any pending PRE versions. A PRE
release should NOT include bug fixes not available for the previous REL
version unless they are from a design change requiring a new version, or
for a new bug that appeared in the REL release.

/Henrik
Received on Tue Jul 29 2003 - 13:15:54 MDT