Re: [Plplot-devel] Proposal for release schedule

[Alan W. I. <ir...@be...>]

On 2005-02-25 14:47+0100 Rafael Laboissiere wrote:

> * Thomas J. Duck <to...@fi...> [2005-02-24 11:08]:
>
>>      I think that it would be helpful to move toward a modified linux
>> kernel release model.  The idea would be to provide odd numbered
>> "development releases" (e.g., 5.5.0, 5.5.1, etc), followed by even
>> numbered "final releases" (e.g., 5.6.0).
>>
>>      Development releases could be sent out *every few weeks*.  The
>> benefits will be:
>>
>> [...]
>
> IIRC, we already discussed this here and the consensus was that maintaining
> two branches of PLplot would need much more manpower than we can afford.
> However, if you are willing to care of this, I would say go ahead.

Actually, I think Tom's idea will work well even if we stick completely with
CVS HEAD.  In fact, I strongly encourage that since my PLplot experience is
anything done on branches tends to be a one-man show with no group testing
until it is merged into CVS HEAD. You only need a special branch for the
final release if an absolute showstopper bug was discovered that needs to be
addressed sufficiently long after the release that development had moved on.
So I think all that is necessary is to continue our practice of doing an
ordinary tag of the source tree at a final release. This allows us to easily
get back to that version if necessary and establish a special branch if
required to deal with the showstopper fix.  Of course a special branch for
the final release might also be needed if developers needed to do
experimental development right during the final release cycle, but that is
an extremely unusual situation for our group as well.

> I am
> also unhappy with the low frequency of our official releases.  We already
> have the infrastructure in place to make cvs snapshot releases.  It can be
> used as-is for the "development releases" series.
>
>>      I would still like to coordinate a full release this summer,
>> because it has been such a long time since the last one.
>
> According to your plans, the next release will be 5.4.0, right?  If we
> decide to do "development releases" before that one, how are we going to
> number them?

I suggest we simply skip 5.4.0, and start with naming the next development
release 5.5.0.  That is sufficiently unusual that it gives Tom a chance to
talk about it on plplot-general so most PLplot users will be clued in as to
the meaning of the odd numbered releases.  Of course, a note about the
experimental nature of the releases can also be made as part of the
release notes that you make at SourceForge when you do a file release.

I think Tom's idea really boils down to renaming the cvs snapshot releases
we have been making as development releases, doing ordinary tagging of them,
and using the file release mechanism at SF to release them every few weeks.

I think that is an excellent idea. Although the code quality will probably
be the same as the cvs snapshots are now (i.e., pretty good) there is a lot
of power in a name and the development releases will get wider testing as a
result.  Also, we have our own pride as developers and because the
development releases will be available forever (through the source forge
file release mechanism), we will probably make some extra effort for them.
For example, just the simple step of making sure the documentation is always
updated to the CVS version will add a lot of quality to the development
releases.  I assume Tom will at least make a superficial check before each
development release that the development release is buildable on his machine
and also run ./plplot-test.sh to make sure the installed examples work. And
I assume most developers here would make it a point to use the latest
development release tarball as part of their ordinary use of PLplot which
would help to find any distribution problems in the tarball.

In sum, Tom, good idea --- go for it!

Alan
__________________________
Alan W. Irwin
email: ir...@be...
phone: 250-727-2902

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________