On Sun, May 15, 2005 at 12:41:43PM +0000, Casey Allen Shobe wrote: > So anyways, you can ignore that folder in the above list - the > bottom line is that subfolders of INBOX are explicitly named as > such on the filesystem (.INBOX.Test/ instead of .Test/). Thus a > migration from dovecot to binc/courer would result in all folders > appearing moved under INBOX, with INBOX containing a folder named > INBOX with subfolders.
I don't remember if you've tried IMAPdir, but it seems like just what you want. Toy around with it some if you have the time. :) > > >PS: And stay away from version 1; it's in its 70th (!) release > > >candidate > > Oh hey, it occurred to me - that sounds a lot like the linux kernel > :). I'm more concerned about release quality than how many betas > there are. Lots of betas are fine, and I'd rather something be > hammered to death before jumping to version 1.0 instead of a > premature product being prematurely labelled (I'm a bit eccentric > though I suppose, and a perfectionist - I have yet to give anything > I've written the coveted 1.x versioning). This is a very interesting philosophical discussion that is becoming increasingly common with many open source developers sharing your way of reason. From a marketing perspective it's suicide, however, which is also important to consider. I used to think a lot like you, but by merely changing my own reasoning my software automatically becomes more competitive in the marketplace. :) (I make software, software can be useful even if it has bugs, how I deal with bugs is more important than making a bug-free release, version numbers > 1 give the customer the sense of quality and maturity they should have with my products - it's not a quick hack by the neighbourhood geek, I have been doing this for a bunch of years and that shows in my code so it might as well show in the version number too.) This reasoning holds up pretty well, but there are of course several problems with it too. Upgrades can be costly, bugs in financial modules can be costly, etc. It's always a balance, but for open source you still have to be very much in the know to use any product properly with great success and because of that it's ok to have release versions which are less than perfect. To come back on topic I'm glad Binc is past 1.0 and perhaps 1.3 should become 2.0 rather than 1.4? Do you have a release roadmap with features planned for Binc, Andreas? //Peter
