Proposal: Create a 1.0 Timeline

[bradynpoulsen]

Background

Implementing OpenTracing into application frameworks is very useful for teams wanting to get free tracing insights into what's taking time.

Problem

Making the decision to integrate with this library is difficult because it's not clear why it's still in a 1.0-beta stage. The potential for significant enough API or implementation changes that would make the final 1.0.0 release incompatible in many larger frameworks a clear no-go.

Proposal

Let's make a timeline of changes that need to occur before a stable release is GA. As these changes are implemented and released in any beta/rc releases, let's give visibility of that in the timeline showing it has been completed and was released in -betaX or -rcX.

Questions to address

• What features are we lacking?
• What issues are we still experiencing with the existing implementation?

[jcchavezs]

Thanks for raising the issue. Basically we need to settle on the scope API. The long history short is that most of the OT libraries that had to implement this had hard times doing so (we too) and the scope API here was a very early one. I want to change that API and moved into something like ScopedSpan rather than having both scope and span (breaking the Demeter's law every time). I will probably tackle this during the begining of the next year (on holidays now). After that we need mostly implementors feedback and then we can consider getting into the path of 1.0.0. Without implementors feedback there is no way we can call this "stable". Den tir. 11. des. 2018, 20:07 skrev Bradyn Poulsen <notifications@github.com :

…

Background Implementing OpenTracing into application frameworks is very useful for teams wanting to get free tracing insights into what's taking time. Problem Making the decision to integrate with this library is difficult because it's not clear why it's still in a 1.0-beta stage. The potential for significant enough API or implementation changes that would make the final 1.0.0 release incompatible in many larger frameworks a clear no-go. Proposal Let's make a timeline of changes that need to occur before a stable release is GA. As these changes are implemented and released in any beta/rc releases, let's give visibility of that in the timeline showing it has been completed and was released in -betaX or -rcX. Questions to address - What features are we lacking? - What issues are we still experiencing with the existing implementation? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#85>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC7sAvs2g26DCIlYTvmERz7z5lYuZfdoks5u4AJ1gaJpZM4ZODB5> .

[bradynpoulsen]

I'll agree that scope/span isn't very clear (perhaps because I'm not completely familiar with OpenTracing yet).

I've been doing a basic integration for starters using this format:

$tracing = GlobalTracer::get()->startActiveSpan(__METHOD__ . '.example');
try {
    doSomething();
} finally {
    $tracing->getSpan()->finish();
}

[monteiro]

@jcchavezs do you think it makes sense this library to list all supported clients? (e.g. jaeger). We are trying to implement opentracing with PHP and we are feeling that there is no official client. We currently have opentracing for NodeJS and Go services.

[jcchavezs]

Make sense as long as we don’t end up with a big list of unnofficials. In zipkin there is only one client supported and used (that I support). I don’t know of the jaeger clients now but I remember there were a few with no agreement. tor. 11. apr. 2019 kl. 15:15 skrev Hugo Monteiro <notifications@github.com>:

@jcchavezs <https://github.com/jcchavezs> do you think it makes sense this library to list all supported clients? (e.g. jaeger <jukylin/jaeger-php#10>). We are trying to implement opentracing with PHP and we are feeling that there is no official client. We currently have opentracing for NodeJS and Go services. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#85 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC7sAnWVklTIkXpd7xhQS42dHMzK3eJBks5vfzVrgaJpZM4ZODB5> .

-- -- José Carlos Chávez Teléfono: 708-5422 Anexo 918 Móvil: 962840384 / 946177706 RPM: *6975470 Nextel: 617*7706

[piotrooo]

I think now we should create, a 1.0.x branch with the current version of lib. We should still develop in the master branch and then merge into branches.

I prefer a "trunk-based development" (https://stxnext.com/blog/2018/02/28/escape-merge-hell-why-i-prefer-trunk-based-development-over-feature-branching-and-gitflow/).

[bradynpoulsen]

While I agree that basic git-flow encapsulated in a single repository can get messy (I also prefer merging into master instead of having a develop branch), but luckily the project is being developed in GitHub which provides forking and pull requests. I would argue that only a release manager, for non-development purposes, should be the one to manage/create/delete branches in the primary repo. Everything else, features, hotfixes, bugs, chores, etc. are excellent candidates for personal forks of individual developers.

[piotrooo]

I'll try to clarify. We have e.g. following structure of repo:

• master (branch)
• 1.0.x (branch)
  • 1.0.0 (tag)
  • 1.0.1 (tag)
  • 1.0.2 (tag)
• 1.1.x (branch) (current major)
  • 1.1.0 (tag)
  • 1.1.1 (tag)

Production-ready are branches 1.0.x, 1.1.x and tags: 1.0.0, 1.0.1, 1.0.2, 1.1.0, 1.1.1.

You (@bradynpoulsen) as a good in inventing new features make your own fork, implements feature and then create a PR. Project manager @jcchavezs review that awesome PR and merge it into master and always into current major, unless that new feature should introduce new branch (in our case 1.2.x) and tag (1.2.0) so should stay in master until next release (e.g.: because of BC problems).

Me as a guy who like a fixing bugs, make my own fork, implement a bugfix and then create a PR. Project manager @jcchavezs review that embarrassing PR and merge it into master and he decides that fixes should be in all versions of our lib, so merge it into branch 1.0.x and 1.1.x.

[bradynpoulsen]

@piotrooo I agree about the trunk concept :). I apologize if it appeared I was disagreeing with you; I meant to say I disagree with that article's initial argument about git-flow being messy because it's under the assumption that organization does not utilize forks/pull requests.

One clarification I would make in the case of the bug fix being appropriate for 1.0.x and 1.1.x, you can't simply merge the fix into those branches. You have to, first, make sure the bug fix is based on the 1.0.x (or latest 1.0.n tag). Otherwise, you would have to rebase the bug fix changes against 1.0.x and drop all other commits (which is pretty messy). "Hopefully", that will not be the case and the bug fix can be identified as applicable to 1.0.x and 1.1.x while it is still in the issue report phase :). Once that bug fix has been based on 1.0.x and a PR opened, the easiest way I've seen to avoid merge conflicts is to merge bug-fix-branch into 1.0.x (released as 1.0.3), then 1.0.x into 1.1.x (released as 1.1.2), then 1.1.x into master.

The only scenario I've seen deviate from what you discussed and with the clarification above has been known long-running features sponsored by the project with multiple collaborators where I've used epic/<long-running-implementation-name> staging branches that PRs get merged into first, and then a final sanity review when that epic branch gets PRed into master once the "epic" has been completed. In a trunk-based project, perhaps that would best be hosted on the fork of the epic "sponsor" or "lead"?

I think we're on the same page assuming that clarification is making correct assumptions 😄 (I apologize if this thread was an inappropriate place to have this conversation)

[piotrooo]

Let's think about following case.

• master (7.3, 8.0)
• 1.0.x (branch) (7.0, 7.1)
• 1.1.x (branch) (7.1, 7.2, 7.3)
• 2.0.x (branch) (current major) (7.3, 8.0)

Branches are supporting following PHP versions. You report the bug that affecting all of those branches. So, how I should merge your bugfix?

IMHO I should create a bugfix for master (working with 7.3), then merge it into 2.0.x, check that fix is applicable for 1.1.x and 1.0.x and what if not? Who (and how) should provide bugfix for rest of the branches?