If there is a 5.3.2 release, we should probably also backport this one: SOLR-8269 <http://issues.apache.org/jira/browse/SOLR-8269>: Upgrade commons-collections to 3.2.2. This fixes a known serialization vulnerability
-- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 17. des. 2015 kl. 07.35 skrev Anshum Gupta <ans...@anshumgupta.net>: > > Yes, there was already a 5.3.2 version in JIRA. I will start back-porting > stuff to the lucene_solr_5_3 branch later in the day today. > > > On Thu, Dec 17, 2015 at 11:35 AM, Noble Paul <noble.p...@gmail.com > <mailto:noble.p...@gmail.com>> wrote: > Agree with Shawn here. > > If a company has already done the work to upgrade their systems to > 5.3.1 , they would rather have a bug fix for the old version . > > So anshum, is there a 5.3.2 version created in JIRA? can we start > tagging issues to that release so that we can have a definitive list > of bugs to be backported > > On Thu, Dec 17, 2015 at 10:27 AM, Anshum Gupta <ans...@anshumgupta.net > <mailto:ans...@anshumgupta.net>> wrote: > > Thanks for explaining it so well Shawn :) > > > > Yes, that's pretty much the reason why it makes sense to have a 5.3.2 > > release. > > > > We might even need a 5.4.1 after that as there are more security bug fixes > > that are getting committed as the feature is being tried by users and bugs > > are being reported. > > > > On Thu, Dec 17, 2015 at 3:28 AM, Shawn Heisey <apa...@elyograg.org > > <mailto:apa...@elyograg.org>> wrote: > >> > >> On 12/16/2015 2:15 PM, Upayavira wrote: > >> > Why don't people just upgrade to 5.4? Why do we need another release in > >> > the 5.3.x range? > >> > >> I am using a third-party custom Solr plugin. The latest version of that > >> plugin (which I have on my dev server) has only been certified to work > >> with Solr 5.3.x. There's a chance that it won't work with 5.4, so I > >> cannot use that version yet. If I happen to need any of the fixes that > >> are being backported, an official 5.3.2 release would allow me to use > >> official binaries, which will make my managers much more comfortable > >> than a version that I compile myself. > >> > >> Additionally, the IT change policies in place for many businesses > >> require a huge amount of QA work for software upgrades, but those > >> policies may be relaxed for hotfixes and upgrades that are *only* > >> bugfixes. For users operating under those policies, a bugfix release > >> will allow them to fix bugs immediately, rather than spend several weeks > >> validating a new minor release. > >> > >> There is a huge amount of interest in the new security features in > >> 5.3.x, functionality that has a number of critical problems. Lots of > >> users who need those features have already deployed 5.3.1. Many of the > >> critical problems are fixed in 5.4, and these are the fixes that Anshum > >> wants to make available in 5.3.2. If a user is in either of the > >> situations that I outlined above, upgrading to 5.4 may be unrealistic. > >> > >> Thanks, > >> Shawn > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> <mailto:dev-unsubscr...@lucene.apache.org> > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> <mailto:dev-h...@lucene.apache.org> > >> > > > > > > > > -- > > Anshum Gupta > > > > -- > ----------------------------------------------------- > Noble Paul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > <mailto:dev-unsubscr...@lucene.apache.org> > For additional commands, e-mail: dev-h...@lucene.apache.org > <mailto:dev-h...@lucene.apache.org> > > > > > -- > Anshum Gupta
