Hello, I''ve completed the update of all my servers to the new mongrel. No problems whatsoever to report, well done. But, I have some colleagues who are wondering what the primary improvements are to mongrel with this new release. I read the Change log but it was a bit cryptic for me. Can anyone provide an executive summary of why 1.0.1 is better than 0.3.xx? a few main bullet points would do fine... Thanks, Andy Koch
"First, really they should do their own research and try it in a test scenario. Reading a changelog isn''t going to help their anxiety over the upgrade. I never read changelogs since half the time they lie about the new version''s actual stability and improvements for *my* application. Instead I test the new software and if it works then I plan an upgrade very carefully." I agree with you on the stability lying on many changelogs but still it is nice as a user to know _exactly why_ a new version was released. It is nice to have that info just so you know exactly how important/urgent it is to upgrade so I can more appropriately prioritize my administration tasks. That said, I am by no means requesting you do things differently; I am perfectly fine looking through the svn logs at svn://rubyforge.org/var/svn/mongrel. Kyle Kochis
On Fri, 26 Jan 2007 14:23:48 -0800 Andy Koch <andy.koch at pc-doctor.com> wrote:> Hello, > > I''ve completed the update of all my servers to the new mongrel. No > problems whatsoever to report, well done. > > But, I have some colleagues who are wondering what the primary > improvements are to mongrel with this new release. > > I read the Change log but it was a bit cryptic for me. > > Can anyone provide an executive summary of why 1.0.1 is better than 0.3.xx? > > a few main bullet points would do fine...First, really they should do their own research and try it in a test scenario. Reading a changelog isn''t going to help their anxiety over the upgrade. I never read changelogs since half the time they lie about the new version''s actual stability and improvements for *my* application. Instead I test the new software and if it works then I plan an upgrade very carefully. Second, they sound like the kind of cats who shouldn''t upgrade. If everything works for them and there''s no problems then there''s no point. When they do go with an upgrade they should test everything out again before moving to the new version. If they''re seeing memory hogging, stuck processes, or other similar problems then they should upgrade. Third, there aren''t major improvements in Mongrel directly, just mostly fine tuning and touch-ups. The main improvements come from fastthread which Mongrel will use if installed. I think that right there should be the biggest reason to move to 1.0.1. Finally, if they want support from people on the mailing list or from me they should upgrade so we know what we''re dealing with. -- Zed
> That''s really the best I can do without help. I have to automate > things, and svn changelogs blow so I''m stuck. Without automation I''d be > burdened with writing this same information over and over again in > various forms. Considering there''s a wealth of change information > including svn logs, atom feeds, news announcements, bug trackers, > forums, and mailing lists it''s not like there''s nothing. So, I tell > people if that''s not enough, then your requirements are exceptional and > you should do something for yourself to solve the problem. > > But, one thing I don''t hear is a solution. Just a criticism. If you''ve > got a particular tool that automates change logging the way you like it > and want to do the work to get it implemented in the mongrel build > process then step up and help. Otherwise, what I got is the best I can > do given my time constraints.Wahoo! I can finally contribute something useful... well, I didn''t write it, but it will help with your change log :) http://ch.tudelft.nl/~arthur/svn2cl/ I use it to send out daily change logs to our development team like this: today=`date +"%Y-%m-%d"` cd $HOME/etc/svn2cl-0.6 && ./svn2cl.sh \ --strip-prefix=trunk \ --break-before-msg \ --revision "{$today}:HEAD" --stdout \ file:///svn/cpr/trunk The above options come pretty darn close to mimicing what people are used to in a change log... all you''d need to do is change the --revision line to match the revisions your interested in and there ya go! No idea how to integrate it into the build process, but I''d be willing to help... -philip
On Fri, 26 Jan 2007 16:57:51 -0700 "Kyle Kochis" <kylekochis at gmail.com> wrote:> "First, really they should do their own research and try it in a test > scenario. Reading a changelog isn''t going to help their anxiety over > the upgrade. I never read changelogs since half the time they lie > about the new version''s actual stability and improvements for *my* > application. Instead I test the new software and if it works then I > plan an upgrade very carefully." > > I agree with you on the stability lying on many changelogs but still > it is nice as a user to know _exactly why_ a new version was released. > It is nice to have that info just so you know exactly how > important/urgent it is to upgrade so I can more appropriately > prioritize my administration tasks. That said, I am by no means > requesting you do things differently; I am perfectly fine looking > through the svn logs at svn://rubyforge.org/var/svn/mongrel.http://mongrel.rubyforge.org/releases/ChangeLog is what, and http://mongrel.rubyforge.org/news.html is why. That''s really the best I can do without help. I have to automate things, and svn changelogs blow so I''m stuck. Without automation I''d be burdened with writing this same information over and over again in various forms. Considering there''s a wealth of change information including svn logs, atom feeds, news announcements, bug trackers, forums, and mailing lists it''s not like there''s nothing. So, I tell people if that''s not enough, then your requirements are exceptional and you should do something for yourself to solve the problem. But, one thing I don''t hear is a solution. Just a criticism. If you''ve got a particular tool that automates change logging the way you like it and want to do the work to get it implemented in the mongrel build process then step up and help. Otherwise, what I got is the best I can do given my time constraints. In other words, criticism without a proposed solution or assistance is meaningless. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://www.awprofessional.com/title/0321483502 -- The Mongrel Book http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
Hi, the problem is not that there is not enough change information but that there is too much. What Andy and probably many others want is a concise document explaining on a high level why someone would like to upgrade to a new release, what pitfalls to avoid and what the most important new features are good for. Most people follow the notion of "never change a running system". Also every change has costs associated to it. In a commercial environment you would need good arguments to spend money. Why should everyone experiment with the same feature set? Of course every application has it''s specifics too. In my experience there is no way to automate such a document. Regards Oliver>> That''s really the best I can do without help. I have to automate >> things, and svn changelogs blow so I''m stuck. Without automation I''d be >> burdened with writing this same information over and over again in >> various forms. Considering there''s a wealth of change information >> including svn logs, atom feeds, news announcements, bug trackers, >> forums, and mailing lists it''s not like there''s nothing. So, I tell >> people if that''s not enough, then your requirements are exceptional and >> you should do something for yourself to solve the problem. >> >> But, one thing I don''t hear is a solution. Just a criticism. If you''ve >> got a particular tool that automates change logging the way you like it >> and want to do the work to get it implemented in the mongrel build >> process then step up and help. Otherwise, what I got is the best I can >> do given my time constraints.