Closed edwarnicke closed 1 year ago
Each project have its own "release tag" regexp, example here: https://github.com/cncf/devstats/blob/master/projects.yaml#L104 All those regexps were guessed by me at the time when given project was added to DevStats. If any project seem to miss releases LMK which one(s) and I'll recheck their regexps.
On Thu, Apr 20, 2023, 16:21 Ed Warnicke @.***> wrote:
Not sure how the devstats is detecting releases for the new http://projecthealth.cncf.io/ … but it shows Network Service Mesh last release as v0.2.0 in 2019…
We’ve been quite busy since then:
https://networkservicemesh.io/docs/releases/v1.8.0/ - which went out in Feb. Our next release 1.9.0 is due in a couple of weeks.
Overall devstat (as is its habit) has done spectacularly better than the other tools I’ve seen on project health in terms of accuracy, but something is a little off in how its detecting releases. How do we go about getting it corrected?
— Reply to this email directly, view it on GitHub https://github.com/cncf/devstats/issues/4, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAS27F74FZXMX3DTKRFOAJDXCFA7VANCNFSM6AAAAAAXFSQRWQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
@lukaszgryglicki
That link is super helpful. A few things I noticed:
https://github.com/cncf/devstats/blob/master/projects.yaml#L538 – ‘mainrepo’ is set to networkservicemesh/networkservicemesh – which was archived years ago when we moved to a multi-repo model.
‘mainrepo’ isn’t really a thing for us… but if you tell me how you are using it, perhaps we can find a repo that will give the desired results? 😊
we use that repo's tags matching its regexps as "releases" that are later used as release names/dates/annotation everywhere in DevStats
On Thu, Apr 20, 2023, 16:34 Ed Warnicke @.***> wrote:
@lukaszgryglicki https://github.com/lukaszgryglicki
That link is super helpful. A few things I noticed:
https://github.com/cncf/devstats/blob/master/projects.yaml#L538 – ‘mainrepo’ is set to networkservicemesh/networkservicemesh – which was archived years ago when we moved to a multi-repo model.
‘mainrepo’ isn’t really a thing for us… but if you tell me how you are using it, perhaps we can find a repo that will give the desired results? 😊
— Reply to this email directly, view it on GitHub https://github.com/cncf/devstats/issues/4#issuecomment-1516442826, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAS27F34L6NTAIROPH567CTXCFCRFANCNFSM6AAAAAAXFSQRWQ . You are receiving this because you were mentioned.Message ID: @.***>
@lukaszgryglicki As long as that's all you use it for, then you could use 'networkservicemesh/api' - as that's where our releases originate. Please note though, our Release notes are always going to be on our site at the corresponding release tab like https://networkservicemesh.io/docs/releases/v1.8.0/ . How are you grabbing release notes?
All release text data is only shown in Project(s) Health
and it uses release name & description from git/GitHub.
Other thatn this we use release datetimes as annotation dates (ranges) so you can see them as verticval lines in chart graphs and are available as ranges in histogram/tables dashboards like, v1 - v2
, v2 - v3
, v3 - now
, etc.
On it.
Done, main repo is now networkservicemesh/api
last release is v1.8.0
.
See:
Closing, please reopen if there is anything else that needs to be done.
Not sure how the devstats is detecting releases for the new http://projecthealth.cncf.io/ … but it shows Network Service Mesh last release as v0.2.0 in 2019…
We’ve been quite busy since then:
https://networkservicemesh.io/docs/releases/v1.8.0/ - which went out in Feb. Our next release 1.9.0 is due in a couple of weeks.
Overall devstat (as is its habit) has done spectacularly better than the other tools I’ve seen on project health in terms of accuracy, but something is a little off in how its detecting releases. How do we go about getting it corrected?