One versioning scheme to rule them all
We are in the process of building new prereleases of all of the elmah.io client integrations, based on our v3 API. While doing so, we are also introducing a new versioning scheme. For an overview of all of our client packages, check out The elmah.io NuGet package landscape post.
It's no secret, that we are fans of SemVer at elmah.io. Having a standard for naming software as well as indicating breaking changes is essential in modern software development. While we have used SemVer to version our client libraries from day 1, we haven't been consistent. That have caused some problems out there, making it hard to understand which versions of
Elmah.Io.Client and the API to use. That's about to change.
From the new prereleases and going forward, the major version of our client libraries follow the API version (currently in version 3). This means that
3.0.42 uses API v3. Same goes for the packages for ELMAH, log4net etc. The
elmah.io package in version
Elmah.Io.Client in version
3.*.*. As specified in SemVer, different versions inside the same major version, will be backwards compatible.
We've bumped all of our packages previously named
3.0.x. The packages will continue to be released and versioned individually for obvious reasons.
As a final note, we have a couple of integrations where we are not in the control of the version number (like the target for Logary). These packages will continue to follow the versioning number schemes defined by the individual projects.
We monitor your websites
We monitor your websites for crashes and availability. This helps you get an overview of the quality of your applications and to spot trends in your releases.
We notify you
We notify you when errors starts happening using Slack, HipChat, mail or other forms of communication to help you react to errors before your users do.
We help you fix bugs
We help you fix bugs quickly by combining error diagnostic information with innovative quick fixes and answers from Stack Overflow and social media.