Skip to content
This repository has been archived by the owner on May 23, 2023. It is now read-only.

Add a CHANGELOG file #251

Merged
merged 3 commits into from
Feb 21, 2018
Merged

Add a CHANGELOG file #251

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
6205cb4
Add a CHANGELOG file
tedsuo Jan 16, 2018
e4fdeeb
incorporating feedback from comments
tedsuo Jan 30, 2018
a47aa44
typo
tedsuo Jan 30, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
Changes by Version
==================
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be used the same formatting symbols as in other markdown files in this repository. e.g. # for headers, * for lists

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was trying to be uniform by copying the style in the go CHANGELOG ;) : https://raw.githubusercontent.com/opentracing/opentracing-go/master/CHANGELOG.md\

We also use .rst instead of .md in some repos. 🤷‍♂️

I prefer # and * so I'll switch to that. Maybe we can standardize and change the others as part of the upcoming "language maintainer" initiative.


v0.31.0 (2018-01-12)
--------------------
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we add one list item per added change? All the following would be in the one list item. Also, add a link to the PR, in some projects there is also a name of the commiter.

Two major changes are missing there:

  • introduction of log fields
  • removed span.log(object) methods

Copy link
Member Author

@tedsuo tedsuo Jan 17, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what you mean by "All the following would be in the one list item." Do you mean only one list item for all the Scope/ActiveSpan changes?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes as it was part of one PR

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked though the PRs... unfortunately I don't think the Pull Requests line up cleanly, as we went through many revisions. I will try to find a middle ground.


- `BaseSpan` and `ActiveSpan` are simplified into a single `Span` class.
- `Scope` replaces `ActiveSpan`, removing the continuation concept. There is no longer a capture phase. Scopes are only activated and then closed.
- `ScopeManager` replaces `ActiveSpanSource`, and is expected to be passed to the tracer at initialization time.
- `ScopeManager.activate(Span,bool)` creates a `Scope` for the current context. The `finishOnClose` flag optionally calls `Span.finish()` on `Scope.close()`.
- `ScopeManager.active()` returns the `Scope` associated with the current context.
- `Tracer.activeSpan()` returns the current value of `Tracer.scopeManager().active().span()` as a convenience.
- `ThreadLocalScopeManager` replaces `ThreadLocalActiveSpanSource`. It still uses thread-local storage for tracking active spans, but removes the reference counting used previously for span lifetime handling.