prometheus
Release 1.0.0 Brainstorming
I'm considering to start a release 1.0.0 branch. Rel. 1.0.0 would be an opportunity for breaking changes.
I'm creating this ticket to collect some ideas. If you have anything that you think should go into 1.0.0 please comment here. And if you have an opinion on something others have proposed, please go ahead and start a discussion here.
Proposal: Compatibility with Jigsaw (Java module system).
Currently multiple Maven artifacts expose the same Java package, which makes it impossible to use them as modules in the Java module system. With rel 1.0.0 we should rename the Java packages to make sure that the package structure is compatible with Jigsaw (we can't have multiple Maven modules implementing classes in the same Java package). See also #712.
Proposal: Renaming the default exports.
Some of the default exports from simpleclient_hotspot don't follow the OpenMetrics naming conventions, and some of the metric names are inconsistent (use of the jvm_ prefix). We should rename them.
Not sure about this one, but I feel some Maven modules could have more descriptive names:
simpleclient_common->prometheus_textformat?simpleclient->prometheus_metrics?- Rename
simpleclienttoprometheuseverywhere? parent-> ???
The downside is that this would break the version history in the Maven repository.
and some of the metric names are inconsistent (use of the jvm_ prefix). We should rename them.
Can you be more explicit? As far as I'm aware, everything has an appropriate prefix already.
~~Since your thought is that Rel. 1.0.0 would have breaking changes do we drop support for Java 6/move to Java 8 as the baseline supported version? (Maybe this is required for Jigsaw support)~~
I see that Java Jigsaw support requires Java 9.
Proposal: Compatibility with Jigsaw (Java module system).
Currently multiple Maven artifacts expose the same Java package, which makes it impossible to use them as modules in the Java module system. With rel 1.0.0 we should rename the Java packages to make sure that the package structure is compatible with Jigsaw (we can't have multiple Maven modules implementing classes in the same Java package). See also #712.
I like this idea. I'm assuming we'd need to make two separate builds? One that's backwards compatible and one that is Java 9+
I think it's worth considering that Java 8+ for the target. Possibly figure out what changes should happen that don't need to break compatibility with Java 6. Cut a release for that. Then start making the breaking changes.
I didn't take a deeper look into Java modules yet, but my understanding is that a Java module is just a regular JAR file that contains an additional module descriptor (a file named module-info.java). If this is correct, these JAR files could be used as regular JAR dependencies in Java 6,7,8 as well as in Java >=9 if users don't use the module system. However, the additional module descriptor allows users to use the JAR files as Jigsaw module if they want.
Releasing JAR files that can be used as Java modules does not mean we must drop Java 6 compatibility (correct me if this is wrong).
In general, I think we could drop Java 6 compatibility if this keeps us from implementing new features. However, as long as we can implement all features while staying compatible we could as well remain compatible, at least as long as there are officially supported Java 6 versions out there (like Azul's Java 6).
#694 might be an interesting candidate to get out before 1.0
Deprecation in a pre 1.0 and then remove in the 1.0.
1.0.0 would be an opportunity for breaking changes
What makes 1.0.0 more suited for breaking changes than an 0.x.0 release? Aside from getting out breaking changes, what do you want to accomplish with a 1.0 release?
@matthiasr these are great questions.
What makes 1.0.0 more suited for breaking changes than an 0.x.0 release?
The last release with significant breaking changes was 0.10.0, when we switched to OpenMetrics and enforced the _total suffix for counter metrics. Based on the feedback/Github issues, it looks like many people were surprised that updating from 0.9.0 to 0.10.0 was a breaking change. So even though it's technically ok to have breaking changes while the major version number is 0, I am hoping that the next breaking change will be less surprising when we do it while switching to 1.x.x.
Aside from getting out breaking changes, what do you want to accomplish with a 1.0 release?
As client_java implements OpenMetrics, I feel it's time to provide a stable Java API. The API is actually quite stable already, except for the package names not being compatible with Java 9 modules. After fixing that, I think we will be able to guarantee backwards compatibility for future 1.x.x releases.
The backwards compatibility policy JEP 182 means that supporting Java 6 will be possible on Java 9 and Java 11, but support has already been removed from Java 17; 11 and 17 are LTS, 9 is already out of support.
It also looks like some dependencies are not modularised, so that may cause problems for some of the modules. There is a method for handling mixed target versions.
I would be happy to work on modularisation.
Proposal: Code formatting/possibly Checkstyle
Code doesn't appear to have common formatting. Some class files have 2 spaces for indention, other class files have 4 spaces for indention.
Maybe we should implement Checkstyle.
Keep up with new JVM features
- Get data for default exports from JFR events instead of JMX beans
- Use the JEP 408 simple web server instead of com.sun.net.HttpServer for exposing metrics
- etc.
The 1.0.0 release should be structured in a way that allows switching to more modern features without breaking things.
The 1.0.0 release should be structured in a way that allows switching to more modern features without breaking things.
Earlier in the PR the discussion seems to be around breaking things at a 1.0.0. I can see how for this might be useful post-1.0.0. Would it make sense to at least deprecate the JMX beans (with no specific end date)?