The advantage is that there is strength in numbers. There will be a lot of users using the release build and if there is an issue the user can rest assured that there will others who need the same fix on the same revision. (so a better chance of a resolution)
moreover there won't be any half baked fixes in a release On Thu, May 14, 2009 at 6:04 PM, Grant Ingersoll <gsing...@apache.org> wrote: > > On May 13, 2009, at 7:04 PM, Eger, Patrick wrote: > >> +2 >> >> This would be very much appreciated by your users, I at least was >> expecting March :-) We were hoping to release with 1.4 (specifically for >> java replication and field collapsing) but had to redo some plans since >> it seemed to keep slipping. > > It's not like anything all that magical necessarily happens with a release. > Sure, we package up the bits and there is some legal ramifications, I > suppose, but the software is more or less the same. In other words, most > people should be fine with trunk, or some recent revision. In fact if more > people tried out trunk, it would be faster to release b/c we would have more > vetting done. > >> Not complaining, just FYI on our experiences >> (it's a free product after all). A 4-6 month release schedule would be >> ideal for us, whereas it looks like it'll be ~9-10 months currently? >> Again, not complaining, just trying to get SOLR into production! > > http://wiki.apache.org/solr/HowToContribute ;-) > > -Grant > -- ----------------------------------------------------- Noble Paul | Principal Engineer| AOL | http://aol.com
