It sounds good to me. I also quickly tested. Regards JB
On 05/03/2019 08:30, Francois Papon wrote: > Hi, > > The PR builds are ok, I fixed the job configuration about OOM. > > @Brian : have you some advise on how check the Spring upgrades is ok? > > All tests passed and I tested some war samples in a local Tomcat. > > If you are ok I can merge the PR. > > regards, > > François Papon > [email protected] > > Le 16/02/2019 à 18:07, Francois Papon a écrit : >> Thanks Brian, >> >> I understand your thoughts about versioning but I really want to move >> forward on next release and the OWASP check will block us if we don't >> upgrade Spring. >> >> I pushed a PR: >> >> https://github.com/apache/shiro/pull/118 >> >> I had some comments on the PR, don't hesitate to make some polish :) >> >> All tests is ok and I check some of the Spring samples in a local Tomcat >> instance. >> >> PS: We always have some failure Jenkins build on test coverage phase >> about memory but it's not related to this update. >> >> regards, >> >> François Papon >> [email protected] >> >> Le 14/02/2019 à 21:59, Brian Demers a écrit : >>> If you push a branch I can take a look. >>> >>> I'm personally not going to block the update. I thought it was worth >>> bringing up the semver topic, but I don't want us to get hung up on that >>> either, so go for it ;) >>> >>> On Wed, Feb 13, 2019 at 2:18 AM Francois Papon >>> <[email protected]> >>> wrote: >>> >>>> Hi guys, >>>> >>>> Are we ok to upgrade Spring to 4.x in the next 1.4.1 ? >>>> >>>> Regards >>>> >>>> François Papon >>>> [email protected] >>>> >>>> Le 05/02/2019 à 02:54, Brian Demers a écrit : >>>>> But through our transitive dependencies, we are pulling in an updated >>>>> version of Spring which may cause issues. >>>>> (Though I'm guessing most/all projects would manage the dependency >>>> versions >>>>> of Spring and Shiro separately) >>>>> >>>>> This is from semver.org: >>>>> >>>> https://semver.org/#what-should-i-do-if-i-update-my-own-dependencies-without-changing-the-public-api >>>>> What should I do if I update my own dependencies without changing the >>>>> public API? >>>>> >>>>> That would be considered compatible since it does not affect the public >>>>> API. Software that explicitly depends on the same dependencies as your >>>>> package should have their own dependency specifications and the author >>>> will >>>>> notice any conflicts. Determining whether the change is a patch level or >>>>> minor level modification depends on whether you updated your dependencies >>>>> in order to fix a bug or introduce new functionality. I would usually >>>>> expect additional code for the latter instance, in which case it’s >>>>> obviously a minor level increment. >>>>> >>>>> Clear as mud :) I'm fine with either, though personally, I'd lean to >>>> saying >>>>> supporting Spring 4+ is a "feature" (I can just as easily see the its a >>>> bug >>>>> fix view too) >>>>> >>>>> On Mon, Feb 4, 2019 at 4:46 PM Les Hazlewood <[email protected]> >>>> wrote: >>>>>> Not really? Everything I know about semantic versioning indicates it >>>>>> has nothing to do with dependencies or build configuration - it has >>>>>> everything to do with how it might impact your actual existing source >>>>>> code during compilation or runtime. In other words: >>>>>> >>>>>> - Can the user upgrade from their current version to the proposed >>>>>> version and not change a single line of their code or .ini/bean config >>>>>> and then at a later date downgrade back to the currently in-use >>>>>> version of Shiro? If so, it's a point release. That is, I should be >>>>>> able to use 1.4.0, 1.4.1 and then 1.4.9 and then downgrade to 1.4.3 >>>>>> and not change a single line of my source code or .ini/bean config >>>>>> that uses Shiro. >>>>>> >>>>>> - Can the user upgrade from their current version to the proposed >>>>>> version and utilize new classes or methods that don't exist in the >>>>>> current version? If so, it's a minor release. This means I can go to >>>>>> 1.5.0 but not down to 1.4.9 because I might be using something that >>>>>> doesn't exist in 1.4.x. >>>>>> >>>>>> - Can the user upgrade from their current version to the proposed >>>>>> version and will they be required to use different or new classes or >>>>>> methods otherwise their code will fail to compile or run? If so, it's >>>>>> a major release, i.e. 1.x --> 2.x >>>>>> >>>>>> None of this implies build configuration. If I upgrade from 1.4.0 to >>>>>> 1.4.1 and I have to change my *build* config (not my .java files), >>>>>> it's totally fine and doesn't warrant a major or minor release. >>>>>> >>>>>> On Mon, Feb 4, 2019 at 3:05 PM Brian Demers <[email protected]> >>>>>> wrote: >>>>>>> Agreed, but updating to a Spring minor version and the OSGI config also >>>>>>> seems more than a patch fix? >>>>>>> >>>>>>> On Mon, Feb 4, 2019 at 11:25 AM Les Hazlewood <[email protected]> >>>>>> wrote: >>>>>>>> Per semantic versioning, major and minor versions should only be >>>>>>>> incremented if there is a change/addition to the API exposed to >>>>>>>> application developers. If we're just changing pom.xml files, a point >>>>>>>> revision seems more appropriate, no? >>>>>>>> >>>>>>>> On Mon, Feb 4, 2019 at 11:22 AM Brian Demers <[email protected]> >>>>>>>> wrote: >>>>>>>>> +1 >>>>>>>>> we might want to bump the Shiro version to 1.5.0 it sounds like we >>>>>> have >>>>>>>>> Spring version update plus all of the OSGI stuff, >>>>>>>>> Thoughts? >>>>>>>>> >>>>>>>>> On Sun, Feb 3, 2019 at 1:38 AM Jean-Baptiste Onofré <[email protected] >>>>>>>> wrote: >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>> it sounds good to me. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> JB >>>>>>>>>> >>>>>>>>>> On 03/02/2019 07:37, Francois Papon wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I have a local branch with an upgrade of Spring to 4.3.22 wich is >>>>>>>>>>> compatible with JDK 6-8. >>>>>>>>>>> >>>>>>>>>>> All tests passed and I think we could include this upgrade to the >>>>>>>> next >>>>>>>>>>> 1.4.1 Shiro release. >>>>>>>>>>> >>>>>>>>>>> @Brian : we will be ok with owasp check :) >>>>>>>>>>> >>>>>>>>>>> Thoughts? >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Jean-Baptiste Onofré >>>>>>>>>> [email protected] >>>>>>>>>> http://blog.nanthrax.net >>>>>>>>>> Talend - http://www.talend.com >>>>>>>>>> -- Jean-Baptiste Onofré [email protected] http://blog.nanthrax.net Talend - http://www.talend.com
