Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Release Version on 0.13.0 to Align with Semantic Versioning "Breaking Change" Standards #537

Closed
james-m-tubbs opened this issue Jun 3, 2020 · 6 comments

Comments

@james-m-tubbs
Copy link

Hi All,

We should update the version number of the latest release from 0.13.0 to 1.0.0 (or something else) so it aligns with the semantic versioning standard for backwards incompatible changes. Since the release is going to break pretty much all promql associated with the exporter it's worth doing.

More Info: https://semver.org

@martinlindhe
Copy link
Collaborator

martinlindhe commented Jun 3, 2020

We bumped minor versions in the past for this project to indicate breaking changes [1]
It has also been noted in the release notes this time and in the past.
I also don't think we ever made a decision about following semver.org.

(The semantic versioning we've applied is more like minor version may indicate breaking changes but many times just indicated larger new features landed, patch version should be fully safe upgrades and major version we have never bumped).

I have no strong opinions in the matter but would suggest we start following the same versioning the other prometheus projects may be using.

Maybe this is a good time for an 1.0. Either way the current 0.13 branch is a pre-release while we fix the fallout from the rename.
@carlpett what do you think about an 1.0 following the stabilization of the 0.13 series?

1: https://github.com/prometheus-community/windows_exporter/releases

@carlpett
Copy link
Collaborator

carlpett commented Jun 3, 2020

@james-m-tubbs Semver actually allows for pretty much anything during 0.x.
But spec technicalities aside, I do agree we should be targeting a 1.0 soonish. And probably have some sort of guidelines on what we guarantee to not break (for example, a typo in a metric name is strictly speaking a breaking change, should that then become a 2.0?).

@martinlindhe Agree! Up until now, the looming rename has been blocking a 1.0 from my point of view, so now I think it is mainly about cleaning up so we don't need to make another breaking change again soon.
There's a few things I've had in the back of my mind:

  • Merge the dotnet_* collectors. It should just have been a single one since the start, with subcollectors like we have in a couple of other places.
  • Move the remaining major collectors to perflib. Main risk of breakage would be the service collector, which if I remember correctly doesn't map all that well between WMI<->perflib.

So, what do you think about this rough idea of upcoming releases?

  • 0.13.x will likely be needed for fallout
  • 0.14.x for the couple of outstanding PRs that came in during the rename window + changes mentioned above and anything else we figure out would be good to get done
  • 1.0 🍰

@martinlindhe
Copy link
Collaborator

@carlpett sounds like a solid roadmap to me!

@james-m-tubbs
Copy link
Author

Thanks guys - appreciate it

@Zayan1221
Copy link

Hello - I need some help- I have download wmi_exporter before but did not install i guess-,

Now what should I do for this new change- Can some one help me with Download and install with this new windows_exporter on all the client windows servers , as I have prometheus,Grafana installed on Linux(CentOS 7) server and want to see the Metrics on Grafana

@carlpett
Copy link
Collaborator

carlpett commented Jun 4, 2020

Hi @Zayan1221,
That is quite off-topic for this issue. I would suggest posting on the prometheus-users maillist for help with general setup.

@carlpett carlpett closed this as completed Jun 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants