Awesome Elixir 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 package changelogs on Awesome Elixir unique.

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

Changelog examples

  • Aeron 1.21.2 (August 19, 2019)
    • ➕ Add client close handler to C++ client which can be used to detect close after client/driver timeouts for cleanup. It will be called on any client close including the shared pointer going out of scope and will be called only once.
    • Try to call all the unavailable handlers in Java and C++ clients regardless of how the client gets closed, especially in the case of timeouts.
    • ➕ Add addition relevant fields to Image.toString() method for debugging.
    • 🌲 Correct log position in some cluster event messages which had the potential to be wrong.
    • ⬆️ Upgrade to SBE 1.13.2.

    Java binaries can be found here...

  • Light-Java 1.6.7 (August 16, 2019)

    1.6.7 (2019-08-16)

    🔀 Merged pull requests:

  • 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

Recent releases