Hello gabriele,

gr> Thursday ha scritto:
gr> :
>> 
>> 1. a more formal release process--this could be as simple as documenting
>> what level of testing goes into changes to the stable vs dev branches
>> before they are committed to CVS.

gr> just my 2cents on this:
gr> I think this is really a worthwhile goal.
gr> I'd like to have a slightly more formal process like
gr> - set a not huge timing for the each .point release (i.e. 4 months). I'd
gr> like this to be short, pointing people to 'stable snapshot' does not
gr> give the same feeling that "use 1.8.3".

I hope we do not - at least with the current ruby development process.

You can't use binary extensions that are compiled against 1.8.1 with
1.8.2 even when the version number suggests this. So as long as the
core team is not willing/able to garantee API stability between patch
releases the situation gets worse.

There are already to much projects out there that are simply out of
date and do not work very well because of the backward compatibility
problem.

gr> - Put someone in charge of it.
gr> - After a fixed period (i.e. after 2 months) declare real feature freeze
gr> (some stuff could change in this period, think of 
gr> RSS::Parser/Maker,cvs.rb,Tk changes) and just fix bugs.


-- 
 Best regards,                        emailto: scholz at scriptolutions dot com
 Lothar Scholz                        http://www.ruby-ide.com
 CTO Scriptolutions                   Ruby, PHP, Python IDE 's