Jackson 2.10 pre-release, 2.10.0.pr1, available

[Tatu Saloranta]

After multiple delays, we finally have the first
pre-release/release-candidate of Jackson 2.10 -- version 2.10.0.pr1.
It is released in hopes of getting more testing by community, so that
we can minimize number of regressions, as well as better documented
observed differences (beyond what is included in github issues
included in release notes).

Full set of changes can be found from the usual place:

https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.10

which is in addition to everything that has been included up to
version 2.9.9 (and `jackson-databind` 2.9.9.1 micro-patch).

I will write a brief overview of what is new with 2.10, but as a
teaser, here's a super terse quick list to whet your appetite.

1. Safe(r) Default Typing! (see
https://github.com/FasterXML/jackson-databind/issues/2195)
2. Java Module info added: now Java 9+ module system can use Jackson
components "natively", and not just with minimal "automatic module
name"
3. Builder-based construction of `ObjectMapper`, `JsonFactory`: allows
easier configuration, esp. of non-JSON features -- but also helps with
eventual upgrade to 3.0 which only supports builder-based approach
(2.x will still support direct construction)
4. JsonNode improvements: is `java.io.Serializable`,
`JsonNode.toString()` IS both guaranteed to produce valid JSON (unlike
before) AND relatively efficient (uses default-configured
`ObjectMapper`)
5. Support for Eclipse Collections (new datatype module)

plus as usual, a long list of various fixes that did not make it in
previous 2.x version.

-+ Tatu +-

[Tim Jacomb]

Hi 

Just a question on the naming of this release (2.10.0.pr1),

Is this pr suffix normal for jackson for a preview release?

We have a couple of tools we use for dependency updates and they don't handle this naming format (pr1)1, 2

i.e. our repos keep notifying us there's a dependency update available but we don't wish to update to it because it's a pre-release version, (we have workarounds but it's all per repo config and we have a lot...).

1. dependabot, (supported patterns)

2. gradle-versions-plugin (default patterns)

Ideally a regular suffix would be used such as alpha, beta or rc (release candidate), so that tooling in the ecosystem doesn't need to adapt to another format.

Sorry if this isn't the right place to ask about it.

Kind regards

Tim

[Tatu Saloranta]

On Mon, Jul 22, 2019 at 8:04 AM Tim Jacomb <timja...@gmail.com> wrote:
>
> Hi

Hi!

>
> Just a question on the naming of this release (2.10.0.pr1),
> Is this pr suffix normal for jackson for a preview release?

Yes, it was used with 2.9:

https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind

and prior to that we have tried similar approach, although some
variations (rc -> release candidate).

> We have a couple of tools we use for dependency updates and they don't handle this naming format (pr1)1, 2
> i.e. our repos keep notifying us there's a dependency update available but we don't wish to update to it because it's a pre-release version, (we have workarounds but it's all per repo config and we have a lot...).
>
> 1. dependabot, (supported patterns)
> 2. gradle-versions-plugin (default patterns)
>
> Ideally a regular suffix would be used such as alpha, beta or rc (release candidate), so that tooling in the ecosystem doesn't need to adapt to another format.
>
> Sorry if this isn't the right place to ask about it.

It is unfortunate that there isn't (... as far as I know...) much in
way of standardization.
I don't think Maven gives any specific semantics, beyond using
alphanumeric ordering for that part of version ("qualifier"?). I don't
think if Gradle has well-documented semantic rules here

History of attempts so far has been such that with 2.7 we found out
that use of hyphen (2.7.0-rc1) broke some platforms/tools (OSGi?).
which lead to adoption of 4-part versioning. Choice of "pr" over "rc"
was simply due to what I thought would be better semantics: these are
not release candidates in the sense that no changes were planned.

But... had I known that one works better with some tool chains, I
would have considered that option better than alternatives.
Unfortunately I do not remember hearing about this before, so no
correction were made since 2.9.

So. At this point I think it would make sense to learn more about what
practices would work best. I am open to changing naming, and was
actually sort of considering alpha/beta/delta/gamma as a possibility.
`rc` has been used in the past and I am not against using it iff there
are clear benefits.

I would be interested in hearing from others: any additional pointers,
suggestions, feedback? At very least it would be good to figure out
improved naming for 3.0.x releases, if nothing else. (with 2.10.x
there is also the question of continuing with `prX` since there is
already one out, so problem already exists)

-+ Tatu +-

> --
> You received this message because you are subscribed to the Google Groups "jackson-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/00aa2600-0eb9-4e91-bb97-a1f076cb54dd%40googlegroups.com.

[Ari Maniatis]

I came to find this mailing list just to understand what pr means. So for me, a vote for using common industry accepted terms:

* alpha (2.9a1) if there are more features still to be added

* beta (2.9b1) if there are more bug fixes likely before the final release, but all the features are done

* release candidate (2.9rc1) if this is absolutely the final release and it just need a few more eyes before making it final

The above naming means no one needs to go looking in mailing lists to figure out what is happening. And my tooling will automatically understand which is the latest stable release.

Thanks

Ari

[Tatu Saloranta]

On Mon, Aug 12, 2019 at 8:41 PM Ari Maniatis
<aristedes...@gmail.com> wrote:
>
> I came to find this mailing list just to understand what pr means. So for me, a vote for using common industry accepted terms:

I was under impression that "pr" for "pre-release" would actually we
quite widely known.
I guess I learned something knew.

Thank you for your suggestions... some comments:

> * alpha (2.9a1) if there are more features still to be added
> * beta (2.9b1) if there are more bug fixes likely before the final release, but all the features are done

These are bit difficult to actually predict but I guess I could (if it
was chosen) to simply use "alpha" for most part. I'd prefer full
"alpha" over "a", as latter has no semantics at all (and personally
I'd see it as more, not less, confusing than "pr")

> * release candidate (2.9rc1) if this is absolutely the final release and it just need a few more eyes before making it final

This is why changed away from "rc" (it was used for some earlier minor
versions), as it suggests the idea that version might become actual
release. I don't think any of pre-release versions has ever actually
been published as minor version.

> The above naming means no one needs to go looking in mailing lists to figure out what is happening. And my tooling will automatically understand which is the latest stable release.

I don't think this is really true, without seeing documentation that
confirms this. While humans are familiar with alpha and beta, Maven
does not have intrinsic notion (AFAIK) beyond basic lexicographic
(alphabetic) ordering, which does guarantee proper sorting.

I am also not sure it is safe to leave out third digit; and I think
some platforms (OSGi) will not work well without separating dot
between last digit and qualifier.

So. While I agree with need to improved there needs to be better
explanation of exactly why a schema works better for tooling. One
example I have seen is Hibernate:

https://mvnrepository.com/artifact/org.hibernate/hibernate-core

which for some reason assigns "Final" as qualifier for actual
releases. I don't like that convention but would like to know if there
is a solid reasoning for it.
Guava:

https://mvnrepository.com/artifact/com.google.guava/guava

does not do any pre-releases, although it used to use "rc". But they
play pretty fast and loose with compatibility anyway so that is
probably not a model to follow.

As to "pr1" -- as an example -- it does work wrt ordering of those
versions as before ("older") than actual release, as per:

https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN400

Anyway... I still want to some explanation of how tools other than
Maven make use of qualifier conventions. Perhaps libraries/frameworks
document it. Or maybe it's cargo-cult/voodoo all the way. But I do not
think there are "well-known standards" at all, considering wide
variety of versions.

-+ Tatu +-