Awesome Java has a "changelog" section under all projects. You can find it next to the "Repo" button in the header. There are two features that make it unique.

  1. It is an aggregation of parsed "CHANGELOG.md" files and releases information from Github. This way, it is easier to see all changes in a single place and a uniform style.
  2. All changelogs are "emojified". This helps with identifying each change easier. Emojification is achieved by parsing each line and applying a specific emoji based on the first word or some other tokens.

The combination of the above two makes library changelogs on Awesome Java unique.

As you know, an example is worth a 1,000 words 🚀

Changelog examples

  • Reactive Streams 1.0.3-RC1 (August 15, 2019)

    Announcement:

    ⚡️ We—the Reactive Streams community—are pleased to announce the immediate availability of Reactive Streams 1.0.3-RC1. This update to Reactive Streams brings the following improvements over 1.0.3-RC1.

    Highlights:

    • Specification
    • Interfaces
      • No changes
    • Technology Compatibility Kit (TCK)
    • Examples
      • No changes
    • Artifacts
      • FlowAdapters artifact removed, FlowAdapters moved into the core jar (#424)

    Specification clarifications 1.0.3-RC1

    🔀 Glossary term "External synchronization" replaced by "Serial(ly)"

    1.0.2: Access coordination for thread safety purposes implemented outside of the constructs defined in this specification, using techniques such as, but not limited to, atomics, monitors, or locks.

    1.0.3 In the context of a Signal, non-overlapping. In the context of the JVM, calls to methods on an object are serial if and only if there is a happens-before relationship between those calls (implying also that the calls do not overlap). When the calls are performed asynchronously, coordination to establish the happens-before relationship is to be implemented using techniques such as, but not limited to, atomics, monitors, or locks.

    Publisher Rule 3 (Rule and Intent clarified)

    1.0.2: onSubscribe, onNext, onError and onComplete signaled to a Subscriber MUST be signaled in a thread-safe manner—and if performed by multiple threads—use external synchronization.

    🚦 The intent of this rule is to make it clear that external synchronization must be employed if the Publisher intends to send signals from multiple/different threads.

    1.0.3-RC1: onSubscribe, onNext, onError and onComplete signaled to a Subscriber MUST be signaled serially.

    🚦 The intent of this rule is to permit the signalling of signals (including from multiple threads) if and only if a happens-before relation between each of the signals is established.

    Subscriber Rule 1 (Intent clarified)

    1.0.2: A Subscriber MUST signal demand via Subscription.request(long n) to receive onNext signals.

    🚦 The intent of this rule is to establish that it is the responsibility of the Subscriber to signal when, and how many, elements it is able and willing to receive.

    1.0.3-RC1: A Subscriber MUST signal demand via Subscription.request(long n) to receive onNext signals.

    🚦 The intent of this rule is to establish that it is the responsibility of the Subscriber to decide when and how many elements it is able and willing to receive. To avoid signal reordering caused by reentrant Subscription methods, it is strongly RECOMMENDED for synchronous Subscriber implementations to invoke Subscription methods at the very end of any signal processing. It is RECOMMENDED that Subscribers request the upper limit of what they are able to process, as requesting only one element at a time results in an inherently inefficient "stop-and-wait" protocol.

    Subscriber Rule 5 (Intent clarified)

    1.0.2: A Subscriber MUST call Subscription.cancel() on the given Subscription after an onSubscribe signal if it already has an active Subscription

    The intent of this rule is to prevent that two, or more, separate Publishers from thinking that they can interact with the same Subscriber. Enforcing this rule means that resource leaks are prevented since extra Subscriptions will be cancelled.

    1.0.3-RC1: A Subscriber MUST call Subscription.cancel() on the given Subscription after an onSubscribe signal if it already has an active Subscription

    The intent of this rule is to prevent that two, or more, separate Publishers from trying to interact with the same Subscriber. Enforcing this rule means that resource leaks are prevented since extra Subscriptions will be cancelled. Failure to conform to this rule may lead to violations of Publisher rule 1, amongst others. Such violations can lead to hard-to-diagnose bugs.

    Subscriber Rule 7 (Rule and Intent clarified)

    1.0.2: A Subscriber MUST ensure that all calls on its Subscription take place from the same thread or provide for respective external synchronization.

    🔀 The intent of this rule is to establish that external synchronization must be added if a Subscriber will be using a Subscription concurrently by two or more threads.

    *1.0.3-RC1: A Subscriber MUST ensure that all calls on its Subscription's request and cancel methods are performed serially.

    The intent of this rule is to permit the calling of the request and cancel methods (including from multiple threads) if and only if a happens-before relation between each of the calls is established.

    TCK alterations 1.0.3-RC1

    • PublisherVerification.optional_spec105_emptyStreamMustTerminateBySignallingOnComplete fails if the publisher completes synchronously (#422)
    • IdentityFlowProcessorVerification throws NPE when createFailedFlowPublisher returns null (#425)
    • required_spec208_mustBePreparedToReceiveOnNextSignalsAfterHavingCalledSubscriptionCancel does not wait for request before invoking onNext (#277)
    • ✅ Subscriber whitebox verification tests demand (#280)
    • 📚 Incomplete documentation on stochastic tests in TCK (#278)
    • 🐎 TCK performance (#446)
    • ⏱ TCK: Receptacle#expectError timeout approach (#451)

    Contributors


  • Mockito 3.0.5 (August 16, 2019)

    🚀 Release notes were automatically generated by Shipkit

    3.0.5

  • Play 2.8.0-M4 (August 15, 2019)

    🚀 The Play Team is pleased to announce the release of Play Framework 2.8.0-M4. This is the fourth milestone release of Play 2.8.x series. Like all milestone releases, the primary goal is to get feedback, so please let us know if something isn't working or you see something that should be improved. If you are the author of a Play module, we would recommend checking out this release to see how it will affect your module.

    🚀 There are many improvements and changes at this new release, and you can see them all in Github milestone.

    🔄 Changelog

    Some of the most relevant changes are:

    1. Akka 2.6.0-M5: as you can see in our roadmap, support Akka 2.6 is a priority, so we are closely tracking Akka 2.6 milestone releases to discover possible integrations problems sooner than later. 👍 2. Dependency Injection Support for Akka Typed : this milestone introduces better integration with Akka Typed, mainly by supporting multiple flavors of Dependency Injection for Akka Typed Actors. 👉 3. Use Jackson ObjectMapper provided by Akka : which makes it consistent with Akka 2.6 Serialization defaults and also make the object mapper configurable using application.conf. ⚡️ 4. Dependencies updates : thanks to scala-steward, all dependencies were updated to the newest versions. The most relevant updates were jackson-databind to 2.9.9.3, Caffeine 2.8.0, specs2 4.7.0 and Akka HTTP 10.1.9.

    📚 There are also many small updates to other APIs, documentation and configurations. See the full list of changes here:

    1. Github milestone
    2. All changes

    Credits

    Finally, thanks to the community for their help with detailed bug reports, discussion about new features, and pull requests review.

    👍 Thanks to Lightbend for their continued sponsorship of the Play core team's efforts. Lightbend offers commercial support for Play.

    Special thanks to the following contributors who helped with this release: Marcos Pereira, Scala Steward, gurkankaymak, Dale Wijnand, Regan Koopmans, Matthias Kurz, Ander Parra, Eugene Yokota, João Ferreira, xuwei-k, Renato Cavalcanti, Brandon Brown, Sergey Morgunov, Seth Tisue, etienne, Arnout Engelen, igarashi-kazuya, Cédric Chantepie..