On Tuesday 20 March 2007 00:49, Steen wrote: > Mandag 19 marts 2007 19:34 skrev Kern Sibbald: > > After receiving somewhat conflicting input (some pro quick releases, some > > against), I've decided roughly to follow the following strategy: > > > > For the immediate future: > > 1. Observe the progress of our current development work over the next week > > or two. > > 2. As far as I can tell, all the code is stable *except* the new batch > > insert database code, which is not yet of production quality. > > 3. After a week, if it is production quality, then we will release an > > update to 2.0.x that contains the whole of the current development code. > > 4. If after a week, the database code is not production quality, then I > > will merge all the development code except the batch insert database code > > into 2.0.4 and release it in the near future (3 - 6 weeks).
> It is not clear to me if this then includes the features that you mentioned > for version 2.2 in the original post. Seems to me that the marked performance > improvements are so significant that the 2.2 version numbering was reasonable Sorry if that was not clear. I am talking about the same subject. This was a "conclusion" of the prior email. > > > > > > > Longer term: > > While developing the 2.0.x code, we made some 12 releases to version > > 1.38.x. The first few, as with 2.0.x, were primarily bug fix releases, but > > a good part of the subsequent releases were new features, but those which I > > found to be stable and compatible. I would like to continue this sort of > > release procedure. It allows us to make a new incremental release every > > two to four months each time adding new features. Please keep in mind that > > each of the 2.0.x releases as was the case with 1.38.x will remain totally > > compatible. There will be no need as some feared to upgrade lots or clients > > unless you want new features that have been added to the clients. Normally > > new client features don't come along too often, but we will probably have > > one shortly for 2.0.x for Win32, because from what I understand the current > > client does not run on Vista (thanks Microsoft), so we will very likely > > release an update (hopefully sooner rather than later). > > > > Obviously the above means that the 2.0.x feature updates will be limited to > > those that are stable and cause no compatibility problems. Major features > > updates will continue to be spaced at approximately 12-18 month intervals. > > > > Basically this means maintaining the status quo. If someone has some > > problems with this, now is the time to speak up. > Depends on the answer above, as those features are some that I personally just > can't wait to see > > Otherwise it seems as a very good way to keep a stable release for a > reasonable length of time. I am still running 1.38 because it does what I > need it to do, but just those performance improvements give me a good reason > to upgrade, and it is nice if it will then last a while. > > Yes, I don't see any reason to wait for users to benefit from the speed up offered by the red/black restore tree code. For me, this is the main improvement aside from the database batch insert code. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
