On releasing

[Egbert Eich]

Daniel Stone writes:
 > On Wed, Apr 19, 2006 at 09:17:03AM +0200, Egbert Eich wrote:
 > > Furthermore if you realease a module you must expect that people pull 
 > > it and report bugs on it. This may happen half a year or longer down 
 > > the road.
 > 
 > Er, if you're using 3.0.2, asking them to please upgrade to 3.0.3 is an
 > entirely valid strategy, if 3.0.3 has been out for any length of time.

Generally yes.
You always run in situation where this isn't possible for various reasons.
One such reason is that the API has changed (has been extended).
I wonder if we have a policy for this - but this is a different issue
that should not be discussed in this context.
Other reasons may be a lot more trivial and related to how a particular
user operates.

 > 
 > > The more often you release the harder it will be to keep track which
 > > problem has been fixed when - or tell them not to bother to report bugs
 > > unless they have pulled the latest release.
 > 
 > This is a red herring.  Releases are just snapshots of the code in time.

Right.

 > If I break something in April 2006, it doesn't matter if we don't
 > release between December 2005 and December 2006, or if we do regular
 > releases of the module within that time.  The advantage to the latter is
 > that you'll have a slightly more varied sampling point.  But regardless,
 > you'll still have to be binary-searching the revision control system of
 > your choice to find the commit that introduced it.

Well, this is using releases as beta test snapshots. 
I'm aware how hard it is to find the right balance between sufficient 
soak time and reflecting the progress of development in releases in a 
timely manner.
I guess the only thing we can do is to try to summarize best practices
from our experience (and the suggestions people make may vary based on
their indiviual experience). In the end everyone needs to decide for
himself how to do it.

Cheers,
	Egbert.