From: Brendan M. <mc...@cs...> - 2005-06-22 02:48:54
|
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. |
From: Joseph L M. <mu...@le...> - 2005-06-22 13:36:33
|
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 |