Sorry, editing mistake, that should have been *not* necessary, and in fact not desired. StringTemplate 4 changed co-ordinates as a patch release (from 4.0.2 to 4.0.3) causing headaches in class paths and eventually needing to use the dependency plugin's "banned dependencies" feature.
On Tue, Oct 4, 2016 at 10:14 PM Tatu Saloranta <[email protected]> wrote: > On Tue, Oct 4, 2016 at 6:53 PM, Christopher Currie <[email protected] > > wrote: > > I think that if Jackson doesn't take the opportunity to cull the dead API > weight at version 3, it will never happen. I support the proposal to make > the Java 8 update in version 3, and shed the API as needed. I also agree > that changing the Maven co-ordinates is necessary. > > > I was actually thinking & suggesting not changing Maven co-ordinates, due > to that significantly slowing uptake of 3.x. As of now, Jackson 2.x is only > about 2x as widely used as 1.x, after 4 years. > > Question of Maven coordinates is tied to the question of Java package as > well. If only Maven group id was changed, upgrade could still be simple -- > only pom change needed. The big difference is with Java package, as > changing that will require sizable (if very mechnical, at least with 1.x -> > 2.x) changes. > > But if only changing Maven coordinates, there's the nasty possibility of > classpath clashes; in fact, this can be worse than not changing Maven > package. So I guess it's both Maven and Java package, or neither. Just one > does not make as much sense. > > Anyway. I don't feel huge need to make drastic API changes so it is quite > possible to go 3.0 but only really base that on JDK baseline change, and > not on public API change. That is one of options. > > -+ Tatu +- > > > > > Christopher > > On Tue, Oct 4, 2016 at 10:22 AM Tatu Saloranta <[email protected]> wrote: > > Based on feedback, I think that going Java 8 should indeed be signalled > with major version upgrade. > But unlike with 1.x -> 2.x, I think this can and should be done without > changing Maven/Java-package coordinates. This would allow behavior similar > to minor-version update for users who are already on Java 8 (which I > suspect is vast majority); but signal other users that there is something > of _potential_ compatibility problem. > > Now: from that point, we have two choices wrt API changes: > > 1. Consider 2.9 -> 3.0 a minor change, and keep even @deprecated public > API (internal, non-public api is not guaranteed to stay with minor > releases, but we try to give at least one minor version grace-period for > those) > 2. Take the opportunity to do little more changes. Most likely: > - Remove deprecated (at least by 2.8) public methods -- there are some > that date back to 2.0, esp. in `JsonFactory` > - Change some of the defaults. For example: > o Seems like majority of users prefer `FAIL_ON_UNKNOWN_PROPERTIES` > to be `false` (1.x and 2.x have it as `true`) > - Make minor changes to public API that really make sense (that is, > similar to bug fix) but that are not binary or source compatible; mostly to > Tree Model (JsonNode): > o Existing `void` methods that ought to be chainable; add `this` > return type > o Existing methods that do not declare exceptions but should: some > JsonNode methods > > My personal leanings would be towards (2), with some or all of proposed > changes; but I do not assume all users agree. Resulting breakage is nasty > if you are hit by it; especially so for transitive dependencies. > > Now: if and when 2.9 will proceed with Java 7, no changes would be made > until end of the year (that is, at earliest january 2017 for master). But I > would create a Wiki page to collect plans for changes to make, so that for > once these may be discussed a priori. I also plan to send update summaries > when significant changes/additions are made. > > Thoughts? > > -+ Tatu +- > > ps. Anyone with insight on Android's Java 8 plans would be very welcome to > share those. > > > -- > You received this message because you are subscribed to the Google Groups > "jackson-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "jackson-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "jackson-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "jackson-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
