You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Francois Papon <fr...@openobject.fr> on 2019/03/05 07:30:12 UTC
Re: [UPGRADE] - Spring
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
fpapon@apache.org
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
> fpapon@apache.org
>
> 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 <fr...@openobject.fr>
>> wrote:
>>
>>> Hi guys,
>>>
>>> Are we ok to upgrade Spring to 4.x in the next 1.4.1 ?
>>>
>>> Regards
>>>
>>> François Papon
>>> fpapon@apache.org
>>>
>>> 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 <lh...@apache.org>
>>> 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 <br...@gmail.com>
>>>>> 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 <lh...@apache.org>
>>>>> 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 <br...@gmail.com>
>>>>>>> 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é <jb@nanthrax.net
>>>>>>> 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é
>>>>>>>>> jbonofre@apache.org
>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>
Re: [UPGRADE] - Spring
Posted by Francois Papon <fr...@openobject.fr>.
Cool :)
I will merge it
regards,
François Papon
fpapon@apache.org
Le 06/03/2019 à 21:25, Brian Demers a écrit :
> Sounds good!
>
> On Tue, Mar 5, 2019 at 11:45 PM Francois Papon <fr...@openobject.fr>
> wrote:
>
>> Hi Brian,
>>
>> I removed the spring-xml example because it was using
>> SimpleFormController that is deprecated in Spring 3.x and was removed in
>> Spring 4.x.
>>
>> It was replaced with annotations that is already used in the spring-mvc
>> example.
>>
>> That why I decided to remove it :)
>>
>> regards,
>>
>> François Papon
>> fpapon@apache.org
>>
>> Le 05/03/2019 à 20:46, Brian Demers a écrit :
>>> Took a quick look, the only thing that sticks out is the removal of the
>>> `spring-xml` example.
>>>
>>> Anyone have a strong opinion on keeping this?
>>>
>>> On Tue, Mar 5, 2019 at 3:48 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>>> 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
>>>>> fpapon@apache.org
>>>>>
>>>>> 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
>>>>>> fpapon@apache.org
>>>>>>
>>>>>> 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 <
>>>> francois.papon@openobject.fr>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi guys,
>>>>>>>>
>>>>>>>> Are we ok to upgrade Spring to 4.x in the next 1.4.1 ?
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>> François Papon
>>>>>>>> fpapon@apache.org
>>>>>>>>
>>>>>>>> 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 <
>> lhazlewood@apache.org>
>>>>>>>> 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 <
>> brian.demers@gmail.com
>>>>>>>>>> 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 <
>>>> lhazlewood@apache.org>
>>>>>>>>>> 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 <
>>>> brian.demers@gmail.com>
>>>>>>>>>>>> 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é <
>>>> jb@nanthrax.net
>>>>>>>>>>>> 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é
>>>>>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
Re: [UPGRADE] - Spring
Posted by Brian Demers <br...@gmail.com>.
Sounds good!
On Tue, Mar 5, 2019 at 11:45 PM Francois Papon <fr...@openobject.fr>
wrote:
> Hi Brian,
>
> I removed the spring-xml example because it was using
> SimpleFormController that is deprecated in Spring 3.x and was removed in
> Spring 4.x.
>
> It was replaced with annotations that is already used in the spring-mvc
> example.
>
> That why I decided to remove it :)
>
> regards,
>
> François Papon
> fpapon@apache.org
>
> Le 05/03/2019 à 20:46, Brian Demers a écrit :
> > Took a quick look, the only thing that sticks out is the removal of the
> > `spring-xml` example.
> >
> > Anyone have a strong opinion on keeping this?
> >
> > On Tue, Mar 5, 2019 at 3:48 AM Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
> >
> >> 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
> >>> fpapon@apache.org
> >>>
> >>> 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
> >>>> fpapon@apache.org
> >>>>
> >>>> 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 <
> >> francois.papon@openobject.fr>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi guys,
> >>>>>>
> >>>>>> Are we ok to upgrade Spring to 4.x in the next 1.4.1 ?
> >>>>>>
> >>>>>> Regards
> >>>>>>
> >>>>>> François Papon
> >>>>>> fpapon@apache.org
> >>>>>>
> >>>>>> 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 <
> lhazlewood@apache.org>
> >>>>>> 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 <
> brian.demers@gmail.com
> >>>>>>>> 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 <
> >> lhazlewood@apache.org>
> >>>>>>>> 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 <
> >> brian.demers@gmail.com>
> >>>>>>>>>> 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é <
> >> jb@nanthrax.net
> >>>>>>>>>> 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é
> >>>>>>>>>>>> jbonofre@apache.org
> >>>>>>>>>>>> http://blog.nanthrax.net
> >>>>>>>>>>>> Talend - http://www.talend.com
> >>>>>>>>>>>>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >>
>
Re: [UPGRADE] - Spring
Posted by Francois Papon <fr...@openobject.fr>.
Hi Brian,
I removed the spring-xml example because it was using
SimpleFormController that is deprecated in Spring 3.x and was removed in
Spring 4.x.
It was replaced with annotations that is already used in the spring-mvc
example.
That why I decided to remove it :)
regards,
François Papon
fpapon@apache.org
Le 05/03/2019 à 20:46, Brian Demers a écrit :
> Took a quick look, the only thing that sticks out is the removal of the
> `spring-xml` example.
>
> Anyone have a strong opinion on keeping this?
>
> On Tue, Mar 5, 2019 at 3:48 AM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
>> 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
>>> fpapon@apache.org
>>>
>>> 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
>>>> fpapon@apache.org
>>>>
>>>> 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 <
>> francois.papon@openobject.fr>
>>>>> wrote:
>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> Are we ok to upgrade Spring to 4.x in the next 1.4.1 ?
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> François Papon
>>>>>> fpapon@apache.org
>>>>>>
>>>>>> 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 <lh...@apache.org>
>>>>>> 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 <brian.demers@gmail.com
>>>>>>>> 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 <
>> lhazlewood@apache.org>
>>>>>>>> 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 <
>> brian.demers@gmail.com>
>>>>>>>>>> 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é <
>> jb@nanthrax.net
>>>>>>>>>> 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é
>>>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
Re: [UPGRADE] - Spring
Posted by Brian Demers <br...@gmail.com>.
Took a quick look, the only thing that sticks out is the removal of the
`spring-xml` example.
Anyone have a strong opinion on keeping this?
On Tue, Mar 5, 2019 at 3:48 AM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> 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
> > fpapon@apache.org
> >
> > 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
> >> fpapon@apache.org
> >>
> >> 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 <
> francois.papon@openobject.fr>
> >>> wrote:
> >>>
> >>>> Hi guys,
> >>>>
> >>>> Are we ok to upgrade Spring to 4.x in the next 1.4.1 ?
> >>>>
> >>>> Regards
> >>>>
> >>>> François Papon
> >>>> fpapon@apache.org
> >>>>
> >>>> 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 <lh...@apache.org>
> >>>> 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 <brian.demers@gmail.com
> >
> >>>>>> 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 <
> lhazlewood@apache.org>
> >>>>>> 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 <
> brian.demers@gmail.com>
> >>>>>>>> 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é <
> jb@nanthrax.net
> >>>>>>>> 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é
> >>>>>>>>>> jbonofre@apache.org
> >>>>>>>>>> http://blog.nanthrax.net
> >>>>>>>>>> Talend - http://www.talend.com
> >>>>>>>>>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: [UPGRADE] - Spring
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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
> fpapon@apache.org
>
> 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
>> fpapon@apache.org
>>
>> 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 <fr...@openobject.fr>
>>> wrote:
>>>
>>>> Hi guys,
>>>>
>>>> Are we ok to upgrade Spring to 4.x in the next 1.4.1 ?
>>>>
>>>> Regards
>>>>
>>>> François Papon
>>>> fpapon@apache.org
>>>>
>>>> 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 <lh...@apache.org>
>>>> 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 <br...@gmail.com>
>>>>>> 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 <lh...@apache.org>
>>>>>> 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 <br...@gmail.com>
>>>>>>>> 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é <jb@nanthrax.net
>>>>>>>> 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é
>>>>>>>>>> jbonofre@apache.org
>>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com