+1 for keeping multiple branches for older versions and moving forward to new branch with latest java
On Sun, Sep 21, 2014 at 5:40 PM, Grant Ingersoll <[email protected]> wrote: > > On Sep 19, 2014, at 10:23 AM, Yonik Seeley <[email protected]> wrote: > > > On Fri, Sep 19, 2014 at 7:14 AM, Grant Ingersoll <[email protected]> > wrote: > >> People will upgrade when > >> the new features they want in the latest release outweigh the mythical > pain > >> of upgrading a JDK. > > > > Perhaps the technical pain of upgrade is largely mythical, but it's > > real pain for real users who have no say over what version of Java > > they can run (or at a minimum have to jump through a lot of hoops to > > change the java version). > > Fully well aware of this, but trunk is not, by definition released, so > there is nothing for them to upgrade to. > > > > > There is no right answer... it's a judgement call where we should > > weigh all the factors each time we require a new Java version. People > > may weigh factors differently, but no factor should be dismissed out > > of hand. > > Of course not, just saying I personally think trunk should move forward as > fast as the regular contributors and committers want, which means, we > decide/vote and then move on based on the outcome and that the branches (4x > or 5x or whatever) should be slower to make any changes. People who take > years to upgrade their JDK also likely take years to upgrade Lucene or Solr > or whatever. I'm all for keeping and maintaining older branches for those > who don't want to upgrade as long as the community is willing to support > them. > > As for Doug's comments, I think they reflect a time when we only > maintained one branch and it was more of a forced decision for users. It > isn't as cut and dried anymore with multiple branches, services like Solr > and ES, etc. I do agree, wholeheartedly however, that we should all be > thoughtful and considerate of other's opinions in the process. > > -Grant > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
