On Wed, 2005-09-07 at 07:47 +0200, Grasic Igor wrote: > If I got Robert right, you will start to polish out 5.2.2 line > and together developed 5.3 final version?
That's the intention, yes. > > TA> Yes, 5.2.2 is overdue. > > ...that suppose to mean, that 5.2.2 is mature enough to be some > real version (in few days, weeks,...)? 5.2.2 will be the front-line mature version, yes. It'll basically be bug fixes on top of 5.2.1.2. The 5.3 release will have various new features, which will inevitably need a little shaking down time. The bottom line is that a 5.x.y release will *always* tend to be more reliable than the first 5.(x+1) version. That initial release tends to reveal hidden problems with the new features - if only because more people are trying them out (on a wider range of equipment than the core developers have access to). That first 5.(x+1) version is typically followed by one or more 5.(x+1).y releases. When that flurry of activity has calmed down, *then* it's probably safe to switch to the latest version. But a lot depends on your personal tradeoff between maturity and functionality. > What sense makes 5.1.3.1 (last version at SF)? > > Is there any resonably point to upgrade my 5.2.1.rc2 > to that version 5.1.3.1? No. Not in the slightest. As I said yesterday, you should be looking at upgrading 5.2.1.rc2 to 5.2.1.2. The 5.1.3.1 release is fundamentally *older* code than 5.2.1.2. Don't be fooled by the fact that it was released more recently. It's purely bug fixes on top of the 5.1 code base (which was released back in November 2003). Active development on this line ceased then, and this code became maintenance only. Nothing new will have been added in almost two years. When 5.1 came out, all new work switched to what is now the 5.2.x line, until 5.2 was itself released (last November). At which point the 5.2.x code *also* became maintenance only, and new work switched to the current development line (which will shortly appear as 5.3). At which point *that* code will become maintenance only, and new work will switch to the new development tree. And so on, and so on. Don't worry about release dates - concentrate on the release numbers. Think of them as OIDs, and go for the "lexically next" release :-) Dave ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
