On 2009-10-01 18:25, Matthew Dillon wrote: > 1-October-2009 > > DragonFly 2.4.1 has been released as promised! As we thought, a lot > of minor but annoying issues cropped up with the huge 2.4.0 release. > Most of the issues have been resolved in 2.4.1 and 2.4.1 is now > available for download. > > Due to an unrelated issue with one of our primary mirror sites, if > you do not see 2.4.1 on your favorite mirror you can download it from > http://avalon.dragonflybsd.org/iso-images/ > > http://www.dragonflybsd.org/ > http://www.dragonflybsd.org/release24
First of I want to say thanks to all the developers for their great work, I really appreciate it. And now for my proposal: Is it just my memory or is this not the first time we get a X.Y.1 release quite shortly after the X.Y.0 release? It seems to me like there are a lot more people who download and install the releases than there are people who follow the bleeding edge (or close after) using git. This means that a lot of bugs are only found when the releases are made and people try to install/use them. Quickly following the release a number of bug reports came in with various problems (installer not working correctly, etc.), many of which were quickly resolved. But for people with less technical skill these problems might seem like very severe, and users just wanting to test DragonFly out might come away with a negative impression. The root cause seems to be that there simply has not been enough testing before releasing, since most users will only run the released version. My proposal is that instead of releasing the code as X.Y.0 first make a X.Y.0 RC (Release Candidate). While the RC might not see as much usage as the final release there will still be many more users trying it out than the number of users following the code using git. Then a bit later when bugs have been found and fixed the real release can be made. Of course this is more or less what you are already doing, except for a change of names, X.Y.0 -> X.Y.0 RC, X.Y.1 -> X.Y.0. The only difference is that it will make casual users more aware of the fact that some problems are to be expected. -- Regards Erik Wikström