Blaze-Persistence 1.2.0-Alpha4 Release

Blaze-Persistence version 1.2.0-Alpha4 was just released

By Christian Beikov on 10 February 2018

It has been too long since the last official release, almost a year! But don’t think we didn’t do anything in this time! Many new and shiny features are part of this release.

  • #328 DeltaSpike Data integration

  • #361 Entity view attribute converter support

  • #414 Updatable Entity views

  • #419 Improved keyset pagination implementation

  • #430 Entity view equality now based on entity type rather than entity view type

  • #443 DML support for entity collections

  • #496 Entity View convenience methods for access by id

  • #441 Support for non-public entity view attribute getters and setters

  • #428 New archetypes for Spring Boot, Spring Data, Java EE and DeltaSpike Data

and lots of bugfixes, most notably

  • #417 Single valued id expression optimization was buggy in an edge case

  • #455 Expression cloning didn’t work properly leading to various problems

  • #456, #475, #480 Entity view inheritance was buggy for non-trivial use cases(Thanks for the tests Jan-Willem Gmelig Meyling)

We advise you to update to 1.2.0-Alpha4 as soon as possible to prevent getting hit from the expression cloning issue #455.

Initially, we planned to commit ourselves to implementing updatable entity views in version 2.1, because we thought the experimental support would suffice, but we weren’t happy with that state and decided to implement fully functional updatable entity views already as part of 1.2.0. You can expect a few blog posts about updatable entity views in the upcoming months that show one or another feature in action. We didn’t release a new version because we weren’t fully satisfied with how new features lacked one or another knob to make them really useful in practice. To not rush into an API design that we might regret later, we deferred a release until we verified the design. You might say that we are still in an Alpha stage and the quality expectations of users wouldn’t be very high, but that’s not our intention, we expect a lot of our releases.

We tried to be as backwards-compatible as possible even during our Alpha stage, we just wanted to keep the door open for possible API design alterations in case we got something wrong the first time. After some internal pre-releases and tests on applications we figured it is stupid to keep our users waiting, and it would be better to clean up wrong decisions as part of major releases with specific migration guides. So we decided to switch to a time boxed release model. We will release at least every 8 weeks and anticipate to do a minor or major release. If critical bugs are discovered, we will backport the fix and do bug fix releases of the latest stable version. In general, after a new minor or major release, bug fixes will only be backported to older versions and released on occasion. If we aren’t able to release a minor or major release because we haven’t finished any of the planned features, we will at least release a bug fix version.

For the interested among you, we updated our roadmap to reflect our near future plans.

Stay tuned, the final 1.2.0 release is targeted for end of February.

announcement release
comments powered by Disqus