search

daisy / pipeline

Super-project that aggregates all Pipeline related code, provides a common tracker for Pipeline related issues and holds the Pipeline website
http://daisy.github.io/pipeline
20 stars 20 forks source link

Filters for issues closed in a release is missing issues #703

Open jbrugge opened 10 months ago

jbrugge commented 10 months ago

Expected Behavior

The release notes for the Pipeline2 include links under the "Details" section of each release to see the individual issues closed across the various sub-modules of the Pipeline2. Following those links I am expecting to find specific Github issues that will give more details about the changes in a release.

Actual Behavior

Many of the links do not seem to give useful results, with either issues missing from the list or the list being simply a link to a set of module release commits.

Steps to Reproduce

From the 1.14.13 release notes, the details link goes to a page with 32 issues listed. However, it does not include an issue from pipeline-scripts that was attached to the 1.14.13 milestone, changing a script parameter name and value.

From the 1.14.11 release notes, there are four "FIX" remarks and "Other bugfixes" mentioned, but the links to closed issues in pipeline-assembly, pipeline-modules and pipeline-framework only list "Release 1.14.11" commits. This seems to be the pattern in most of the release details links in releases previous to this as well.

Details

None.

bertfrees commented 10 months ago

The 1.14.13 / 1.14.14 release notes are an attempt to improve things compared to how it used to be done for previous releases.

We used to only list the closed Github issues related to a release. It didn't provide more details for all the items in the release, because we don't always have Github issues or pull requests for all of them. Note also that the "closed issues" links bring you to a "404" page if you are not logged in to Github, which made it less useful too.

As of release 1.14.13 we tried to improve things by listing all the items for the release in a Github "project". The benefit of this approach is that not every project item needs to be a Github issue or pull request, so we can cover all the items in the release with a project item (with or without actual details).

A downside of the Github project approach is that it is apparently not very accessible. I'm still looking for a solution.

From the 1.14.13 release notes, the details link goes to a page with 32 issues listed. However, it does not include an issue from pipeline-scripts that was attached to the 1.14.13 milestone, https://github.com/daisy/pipeline-scripts/issues/111.

This was indeed an oversight. Should be fixed now.

bertfrees commented 10 months ago

@jbrugge Do you have suggestions for how we could further improve the release notes?

jbrugge commented 10 months ago

@bertfrees I think that the 1.14.13/1.14.14 were a big improvement, so I think that is a reasonable direction to continue. I think another section or marker to include is identifying any breaking changes, such as issue #111 in pipeline-scripts mentioned above.

For the past releases, if there is any way to fix the issue query links so that they capture the closed issues for that release, that would be great.

In general my hope is to be able to evaluate the potential cost and value of upgrading to a particular release to be able to plan out our work.

bertfrees commented 9 months ago

@jbrugge That is a very reasonable thing to hope for.

Regarding the suggested section for "breaking changes": that's a good idea, although it is not always so easy to determine what is a breaking change and what isn't. I will try to come up with something for the next release.

For the past releases, if there is any way to fix the issue query links so that they capture the closed issues for that release, that would be great.

I'm not sure what else I can do apart from adding the issue #111 you mentioned to the 1.14.14 list. I know that many of the links of past releases do not give very useful results, but that is not something I'm going to change retroactively. It goes without saying that I'm also not going to create Github projects for all the past releases. What I could try to do is go though all the closed issues that are not assigned to a milestone. But that will be some task. There are apparently 601 such issues, and many of them were purposely closed without an action.