RE: [Vxl-maintainers] vxl releases etc

[Joseph L M. <mu...@le...>]

I don't like solution 2).  Maybe we could more broadly share the work of
a release according to solution 1) in some way.  I don't have a good
understanding of what is involved.  How did the process go last time?
Joe

-----Original Message-----
From: vxl...@li...
[mailto:vxl...@li...] On Behalf Of
Brendan McCane
Sent: Tuesday, June 21, 2005 10:49 PM
To: vxl...@li...
Subject: [Vxl-maintainers] vxl releases etc

G'day maintainers,

I just thought I'd bring up the issue of vxl releases again and propose
a slightly different solution. As the most recent person to put a
release together I can attest that the amount of work is considerable
(probably a couple of days worth), something which I am not that eager
to repeat but would be willing to if we decide it's necessary. 

It seems that vxl has a very different development process to most other
projects. Essentially, the CVS version is almost always in a stable
state, and hence the need for producing specific stable releases is
essentially unnecessary. However, the fact that we have releases
indicates that the CVS version is in someway unstable, and gives the
wrong impression to newcomers. I have 3 possible solutions to this
problem:

1) maintain the status quo, but making some effort to make releases on a
semi-regular basis (perhaps every 12 mths)

2) remove the releases from public view, and tell everyone to get the
latest CVS version as that is stable

3) automatically tar up a new release on a regular time frame (say once
a month, once a week, every day - if it's automatic, who cares?), and
just make that the current release (possibly changing only a minor
version number, eg 1.1.1, 1.1.2, ...).

These options are in increasing order of preference for myself.
Certainly, I don't know how difficult it would be to set up number 3,
but after the initial effort, it should be easy (maybe?). Number 2 is
the easiest to do although this might be daunting for newcomers (I
certainly found it daunting initially). And finally number 1 is my least
preferred option, because it probably will require me to actually do
something.

Upshot is, I think something needs to change. Thoughts?
-- 
Cheers,

Brendan.
------------------------------------------------------------------------
----
Brendan McCane                          Email:  mc...@cs...
Department of Computer Science          Phone:  +64 3 479 8588/8578.
University of Otago                     Fax:    +64 3 479 8529
Box 56, Dunedin, New Zealand.



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Vxl-maintainers mailing list
Vxl...@li...
https://lists.sourceforge.net/lists/listinfo/vxl-maintainers