Add info regarding rolling releases

[ThomDietrich]

The header shouldn't include a version number, this will complicate everything.
I've replaced the WIP note by a Rolling Release note.
Headlines should be capitalized. https://capitalizemytitle.com

@marvinroger the VERSION comments might help you with the webpage project

[ThomDietrich]

@timpur thanks for merging. For future PRs I would suggest to merge single commits via "Rebase and merge" and multiple commits via "Squash and merge". The third option "Create a merge commit" is the one the least favorable in my opinion. Just a thought ;)

[ThomDietrich]

@marvinroger @timpur I've released v3.0.0 and typed down a release note involving buzzword bashing. Feel free to add your toughts: https://github.com/homieiot/convention/releases/tag/v3.0.0

[timpur]

Yep agreed. Will do next time.

[timpur]

@ThomDietrich
Why would you release it when there are multiple talks about some additions to 3.0.0. At lest wait till the community is ready. There are some critical thoughts still. Please change it to pre release.

[marvinroger]

@ThomDietrich I agree about the rebase and squash comments, too. I just disabled the "merge" option.

@timpur I don't think releasing now is a bad idea. The things that are being discussed are not breaking changes as such, so it can be added in the upcoming versions, embracing the rolling release model. 😉

[timpur]

There is one that is breaking, stats implement as a node .... The only reason I say wait because this is breaking and thus we should wait till it's resolved.

It's been mentioned in #61 and #62

[euphi]

$stats can be made a discoverable node within the current hierarchy. We just need to add the discovery-metadata to the $stats hierarchy, so it won't be a breaking change.

[timpur]

I don't think we should even define the stats structure if we go with the node route. Just define possible properties and required props. And leave the rest to discovery defined by our node structure. Reuse as much as possible...

[timpur]

I revoke that last comment. Thought about it some more and yes we can make it backwards compatible. So 3.1.0 but still would of been nice to release it on one go. Feel it was rushed and the community was not part of the decision. There were still pending issue related to 3.0.0 and no notice.

[ThomDietrich]

Breaking or pending changes do not really matter, such will always exist. Version "3.0.0" is nothing magical, even though one might think that. We needed to get a clear versioning system into place as soon as possible. This was the whole point behind #46, which I've opened up half a year ago. Now that the rolling release model is in place we can go forth with all existing discussions. If stats causes the version to jump to 3.1.x, so be it ;) If it is indeed a breaking change we can still argue about wether or not we have to strictly see it as such.

@timpur @euphi is one of you going to propose a PR?

One more thing @timpur, I'm sorry if this step seemed without including the community and without notice. I thought this step was part of the discussion in #46...

[timpur]

@ThomDietrich, it was but limited to #46. I guess those pending discussions are now about v3.1.0 ....