Nicolas Cannasse wrote: >Marco Maggi a écrit : >> Nicolas, >> >> when you bump a version number, is it possible to >> publish a release candidate so that one can understand >> that it is The Time and whip himself into discussing >> issues? And what about micro version releases? > >Release Candidates are good when there are major changes >in the design. When it's mostly bug fixes, I'm not sure >exactly what kind of issues could be discussed ;) > >More seriously, making releases takes time, so I can't >really double this time by making RC everytime. The >best is still to look at CVS/CHANGES on a regular basis >if you want to know what kind of changes are being done.
Marco Maggi a écrit : > Nicolas, > > when you bump a version number, is it possible to > publish a release candidate so that one can understand > that it is The Time and whip himself into discussing > issues? And what about micro version releases? While I can understand the need to keep at minimum the overhead of administration tasks, if you do it that way you destroy the value of having stable releases. You as may well just send an email do the list stating that "now" is the time to check out from the repository. If 12 hours after the stable release a bug report is sent to the mailing list, every long time user knows that the stable release archive is out of date, so it is useless because no micro release will be done. Newbies and people stopping by to take a look do not know, and for them something will not work (like the documentation for 1.8). I cannot believe that you cannot automate the release process with a Neko script. ;) -- Marco Maggi -- Neko : One VM to run them all (http://nekovm.org)
