Merge branch 'main' into event_name_logs

CHANGELOG.md

@@ -8,6 +8,32 @@ The full list of changes can be found in the compare view for the respective rel
 
 - logs: Add top-level `event_name` field to log records instead of `event.name` attribute. [#600](https://github.com/open-telemetry/opentelemetry-proto/pull/600)
 
+## 1.4.0 - 2024-11-20
+
+### Added
+
+* metrics: Add resource attributes and scope to metrics proto diagram. [#519](https://github.com/open-telemetry/opentelemetry-proto/pull/519)
+* metrics: Added json example for exponential histogram. [#580](https://github.com/open-telemetry/opentelemetry-proto/pull/580)
+
+### Changed
+
+* metrics: Clarify aggregation temporality for Summary metric type. [#591](https://github.com/open-telemetry/opentelemetry-proto/pull/591)
+* docs: Remove HTTP 1.1 restriction from Protocol Details [#571](https://github.com/open-telemetry/opentelemetry-proto/pull/571)
+* docs: Update specification to include development profiles [#582](https://github.com/open-telemetry/opentelemetry-proto/pull/582)
+* docs: update references to logging exporter [#581](https://github.com/open-telemetry/opentelemetry-proto/pull/581)
+* Makefile: exclude Profiles protocol from breaking-changes [#576](https://github.com/open-telemetry/opentelemetry-proto/pull/576)
+* Makefile: exclude Profiles service from breaking changes too [#586](https://github.com/open-telemetry/opentelemetry-proto/pull/586/)
+* profiles: align type of index into string table [#557](https://github.com/open-telemetry/opentelemetry-proto/pull/557)
+* profiles: drop Sample.stacktrace_id_index [#575](https://github.com/open-telemetry/opentelemetry-proto/pull/575)
+* profiles: drop BuildIdKind [#584](https://github.com/open-telemetry/opentelemetry-proto/pull/584)
+* profiles: drop Sample.label [#583](https://github.com/open-telemetry/opentelemetry-proto/pull/583)
+* profiles: drop Location.type_index [#578](https://github.com/open-telemetry/opentelemetry-proto/pull/578)
+* profiles: Rename profiles v1experimental to v1development [#585](https://github.com/open-telemetry/opentelemetry-proto/pull/585)
+* profiles: Make mapping in Profile optional [#556](https://github.com/open-telemetry/opentelemetry-proto/pull/556)
+* profiles: Fold the content of pprofextended.proto into profiles.proto, removing ProfileContainer. [#590](https://github.com/open-telemetry/opentelemetry-proto/pull/590)
+* profiles: Improve lookup table pattern use in profiles. [#592](https://github.com/open-telemetry/opentelemetry-proto/pull/592)
+* profiles: Renovations to experimental profiling schema. [#596](https://github.com/open-telemetry/opentelemetry-proto/pull/596)
+
 ## 1.3.2 - 2024-06-28
 
 ### Changed

README.md

@@ -83,14 +83,47 @@ All the additive changes above must be accompanied by an explanation about how
 new and old senders and receivers that implement the version of the protocol
 before and after the change interoperate.
 
-No guarantees are provided whatsoever about the stability of the code that
-is generated from the .proto files by any particular code generator.
-
 ## Experiments
 
-In some cases we are trying to experiment with different features. In this case,
-we recommend using a "development" sub-directory instead of adding them to any
-protocol version. These protocols should not be used, except for
-development/testing purposes.
+### New Experimental Components  
+
+Sometimes we need to experiment with new components, for example to add a
+completely new signal to OpenTelemetry. In this case, to define new experimental
+components we recommend placing new proto files in a "development" sub-directory.
+Such isolated experimental components are excluded from
+above [stability requirements](#stability-definition).
+
+We recommend using
+`Development`, `Alpha`, `Beta`, `Release Candidate`
+[levels](https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/0232-maturity-of-otel.md#maturity-levels)
+to communicate different grades of readiness of new components.
+
+Experimental components may be removed completely at the end of the experiment,
+provided that they are not referenced from any `Stable` component.
+
+Experiments which succeed, require a review to be marked `Stable`. Once marked
+`Stable` they become subject to the [stability requirements](#stability-definition).
 
-Another review must be conducted for in-development protocols to join the main project.
+### Experimental Additions to Stable Components
+
+New experimental fields or messages may be added in `Development` state to `Stable`
+components. The experimental fields and messages within `Stable components` are subject
+to the full [stability requirements](#stability-definition), and in addition, they must be
+clearly labeled as `Development` (or as any other non-`Stable` level) in the .proto file
+source code.
+
+If an experiment concludes and the previously added field or message is not needed
+anymore, the field/message must stay, but it may be declared "deprecated". During all
+phases of experimentation it must be clearly specified that the field or message may be
+deprecated. Typically, deprecated fields are left empty by the senders and the recipients
+that participate in experiments must expect during all experimental phases (including
+_after_ the experiment is concluded) that the experimental field or message has an
+empty value.
+
+Experiments which succeed, require a review before the field or the message is marked
+`Stable`.
+
+## Generated Code
+
+No guarantees are provided whatsoever about the stability of the code that
+is generated from the .proto files by any particular code generator.

opentelemetry/proto/profiles/v1development/profiles.proto

@@ -394,25 +394,6 @@ message Sample {
   repeated uint64 timestamps_unix_nano = 6;
 }
 
-// Provides additional context for a sample,
-// such as thread ID or allocation size, with optional units. [deprecated]
-message Label {
-  int32 key_strindex = 1;   // Index into string table
-
-  // At most one of the following must be present
-  int32 str_strindex = 2;   // Index into string table
-  int64 num = 3;
-
-  // Should only be present when num is present.
-  // Specifies the units of num.
-  // Use arbitrary string (for example, "requests") as a custom count unit.
-  // If no unit is specified, consumer may apply heuristic to deduce the unit.
-  // Consumers may also  interpret units like "bytes" and "kilobytes" as memory
-  // units and units like "seconds" and "nanoseconds" as time units,
-  // and apply appropriate unit conversions to these.
-  int32 num_unit_strindex = 4;  // Index into string table
-}
-
 // Describes the mapping of a binary in memory, including its address range,
 // file offset, and metadata like build ID
 message Mapping {