On Fri, Sep 17, 2010 at 9:45 PM, Chris Hostetter <hossman_luc...@fucit.org>wrote:
> > My unscientific, off the cuff, sociological impression is that once we > moved forward with > the "multi-branch" development plan and created the 3x branch, a lot of > people who use to be the big proponents of regular releases got really > about the freedom involved in working on the trunk, and lost their > motivation to push for releases - because a big part of that motivation > came from the backcompat concerns and the need to churn out releasees > with deprecations so that future versions could move forward ith more > interesting APIs. "trunk" turned into the new hot sexiness. > Maybe, but deprecations shouldn't be the primary motivation for releasing anyway. > I think it's going to take some work just on build/process before we can > get our first "merged" release from 3x. Assuming we improve some > automation while we're at it, then i think it's feasible that we could > start doing releases off of it every couple of months. it would remain > to be seen wether we sould *need* to release that often -- it will > depend on wether anything new gets committed there -- but it would > certianly be nice to be able to. > I can't argue with this, I think the first release will be painful, but thats exactly what I am proposing here, gearing ourselves up for more rapid stable releases. And as far as whether we *need* to release often, i'd like to start looking at whether we *should*. For a realistic example, Solr 3.x got autosuggest functionality. This isn't really a disruptive thing, its not going to introduce a lot of deprecations, etc. do we *need* to release because of that? no. *should* we release? I think yes. To a lot of users, this is a major search engine feature, and they might consider it more "major" than something we consider "major" like flexible indexing. With stable releases, the user can put this feature into production more easily because all the "sexy" stuff is in trunk, not causing them upgrade-hell. This results in a faster feedback process for us, too. I think we should try to avoid massive yearly releases with a ton of changes at once. -- Robert Muir rcm...@gmail.com
