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/02/03 06:37:26 UTC
[UPGRADE] - Spring
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,
--
François Papon
fpapon@apache.org
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
Re: [UPGRADE] - Spring
Posted by Francois Papon <fr...@openobject.fr>.
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 Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
I agree, I prepared some updates on the OSGi front (and fixes). I think
it makes sense to move forward on releases.
Maybe having a regular cadence would be helpful as well.
Regards
JB
On 16/02/2019 15:07, Francois Papon wrote:
> 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>.
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 Brian Demers <br...@gmail.com>.
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>.
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>.
Hi guys,Are we ok to upgrade Spring to 4.x in the next 1.4.1 ?RegardsFrancoisEnvoyé depuis mon smartphone Samsung Galaxy.
-------- Message d'origine --------De : Brian Demers <br...@gmail.com> Date : 05/02/2019 02:54 (GMT+04:00) À : dev@shiro.apache.org Objet : Re: [UPGRADE] - Spring But through our transitive dependencies, we are pulling in an updatedversion of Spring which may cause issues.(Though I'm guessing most/all projects would manage the dependency versionsof 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-apiWhat should I do if I update my own dependencies without changing thepublic API?That would be considered compatible since it does not affect the publicAPI. Software that explicitly depends on the same dependencies as yourpackage should have their own dependency specifications and the author willnotice any conflicts. Determining whether the change is a patch level orminor level modification depends on whether you updated your dependenciesin order to fix a bug or introduce new functionality. I would usuallyexpect additional code for the latter instance, in which case it’sobviously a minor level increment.Clear as mud :) I'm fine with either, though personally, I'd lean to sayingsupporting Spring 4+ is a "feature" (I can just as easily see the its a bugfix 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 Brian Demers <br...@gmail.com>.
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 Les Hazlewood <lh...@apache.org>.
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 Brian Demers <br...@gmail.com>.
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>.
Hi guys,
Thanks for your feedback ;)
I have in mind this roadmap about next releases:
- 1.4.1
* OSGi and Karaf stuff
* Upgrade to Springframework 4.3.22 (to be ok with OWASP)
* Keep compatibility with JDK6
* Upgrade some maven plugin version
- 1.5.0
* Upgrade to JDK8
* Upgrade to Springframework 5.x
* Upgrade dependencies (according to JDK8)
* Add itests for Karaf
* Add samples for Karaf
- 2.0.0
* Compatibility with JDK 9/10/11
* Package refactoring
* API refactoring (according to the 2.0.0 existing branch)
I think we also could start brainstorming about Shiro and Cloud initiative.
Thoughts?
Regards,
François Papon
fpapon@apache.org
Le 04/02/2019 à 20:25, Les Hazlewood a écrit :
> 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 Les Hazlewood <lh...@apache.org>.
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 Brian Demers <br...@gmail.com>.
+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 Jean-Baptiste Onofré <jb...@nanthrax.net>.
+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