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