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 > > > > > > > > >
