BREAKING CHANGES

[thinkingserious]

As a result of your feedback and as a continuation of the execution of our long term roadmap, there will be breaking changes coming soon. The last time we had a major breaking change, it was for the implementation of v3 Web API support. We announced those changes here on GitHub along with some instructions on how to test and provide feedback.

The feedback we got was amazing, but we didn't quite get the amount or thoroughness of feedback we were hoping for.

We want to continue improving this iterative process, so we are reaching out to you for feedback in order to determine the optimum way to move forward as this library is designed to be community driven, SendGrid led.

Please take a moment to share your thoughts with us.

Following are some ideas we are considering, we will likely choose one from Execution and one from Communication, but not all of the items below.

Execution (for large changes):

1. Utilize the pre-release functionality in GitHub to gather feedback and contributions to a specific branch
2. Communicate through a dedicated GitHub issue that references that pre-release branch (e.g C# Dynamic Update)

Communication:

1. Continue using GitHub issues
2. Opt-in email newsletter for announcements
3. Opt-in email mailing list
4. Dedicated social media account (e.g. @sendgrid_libraries)

How do you prefer to get these announcements? Is this too much? Too little? Please let us know!!

As always, we are listening carefully and are looking forward to working with you.

Note: We will always follow the semver.org convention of using major point releases to signify breaking changes. Please DO NOT auto-update your dependencies. It is important to take a look at the CHANGELOG or releases to find out how the breaking changes will impact your code.

[IonicaBizau]

Utilize the pre-release functionality in GitHub to gather feedback and contributions to a specific branch

That's cool, but in addition to it, I'd suggest npm publishing versions like 3.0.0-alpha1, 3.0.0-alpha2, 3.0.0-beta etc—so we can easily npm install them. 🚀

[adamreisnz]

Hi @thinkingserious , I would vote for using the pre-release functionality, and where it makes sense, simply keep communication about a specific item in either the issue or the related PR.

As for communication, definitely keep using GitHub issues. I'm not sure a newsletter would add much value perse, and I wouldn't use a mailing list or social media to communicate with you guys. My preferred way of communicating with authors and other users of open source libraries is purely on Github. I find it the most time effective and the subscribe/unsubscribe granularity you get per topic is a must have.

That way, if you're interested in a particular issue/feature, you can follow it and actively participate in the discussion. If the discussion is about something you have less interest in, you can ignore it and turn off notifications.

With a mailing list or social media account this would be harder to manage.

I agree with @IonicaBizau re. versioning. It would be a good way to install pre-releases of new major versions so we can play around with them, before you make them official.