some release notes entries for 4.11.1 #4256

ThomasBreuer · 2021-02-16T19:21:55Z

The file CHANGES.md now contains the entries about the merged pull requests for GAP 4.11.1, categorized in the same way as for GAP 4.11.0.

What is now MISSING is the information about new and updated GAP packages in 4.11.1, compared to 4.11.0.

~~... currently unstructured, taken from the subset of pull request obtained today with the query~~

~~https://github.com/gap-system/gap/pulls?q=is%3Apr+-label%3A%22release+notes%3A+not+needed%22+-label%3A%22release+notes%3A+added%22+is%3Aclosed+merged%3A2019-09-10..2033-12-31+base%3Amaster+is%3Amerged~~

(It remains to deal with the entries which are still returned by this query. Those entries which are proposed here for addition to CHANGES.md do no longer match the query because now they have the label "release notes: added".)

codecov · 2021-02-16T19:28:40Z

Codecov Report

Merging #4256 (6db0559) into master (935a6f0) will decrease coverage by 2.40%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #4256      +/-   ##
==========================================
- Coverage   82.01%   79.61%   -2.41%     
==========================================
  Files         686      636      -50     
  Lines      296678   271899   -24779     
==========================================
- Hits       243318   216465   -26853     
- Misses      53360    55434    +2074

Impacted Files	Coverage Δ
src/funcs.h	`0.00% <0.00%> (-100.00%)`	⬇️
src/baltree.h	`0.00% <0.00%> (-97.53%)`	⬇️
src/dynarray.h	`0.00% <0.00%> (-94.12%)`	⬇️
lib/helpt2t.gi	`0.23% <0.00%> (-83.14%)`	⬇️
lib/autsr.gi	`1.08% <0.00%> (-66.09%)`	⬇️
src/exprs.h	`6.25% <0.00%> (-62.50%)`	⬇️
src/libgap-api.c	`4.45% <0.00%> (-59.55%)`	⬇️
src/precord.h	`32.35% <0.00%> (-58.83%)`	⬇️
src/sysstr.h	`25.00% <0.00%> (-50.00%)`	⬇️
lib/csetpc.gi	`39.42% <0.00%> (-48.58%)`	⬇️
... and 295 more

CHANGES.md

fingolfin · 2021-02-23T22:36:42Z

There's a typo in one of the commit messages, where it says 4.1.11 instead of 4.11.1 -- but that's hardly important ;-)

CHANGES.md

danielrademacher · 2021-02-24T18:58:58Z

dev/release_notes.readme.md

+
+- Up to now, also the labels `release notes: needed` and `release notes: added` have been used.
+  The first one means that the text for release notes can be found in the body and has not yet been added to `CHANGES.md`, the second one means that the text has been added to `CHANGES.md`.
+  I think that these two labels are obsolete in the new workflow where one can automatically create the current state of the `CHANGES.md` section about the forthcoming release **at any time**.


Yes, I think so too. Maybe we should delete them or replace them by "release notes: needed (please don't use this label anymore. See #4256)" such that everybody can see the new workflow.

This is a good idea. If nobody objects then we should proceed like this.

I don't understand how the new process renders these labels obsolete. How do you distinguish between a PR that nobody has looked at yet from one where the title alone is not suitable for the release notes or from one that is not supposed to go into the release notes?

Also, how would the script distinguish between PRs that are already in the release notes of a previous release from those which are not? One could try to use a date for this, but in the past, this didn't work well (granted, that was before we used the policy of always merging into master and then doing backports and using the backport labels, so perhaps nowadays it works -- but I'd be at least careful about making this assumption...

@fingolfin Concerning the distinction of pull requests w.r.t. release notes via labels, I think that what you ask for corresponds to release notes: approved, meaning that "someone has looked at this pull request, and it is ready for being processed automatically". (One could even evaluate whether the approval was added by the same person who added the label that marks the pull request as relevant for the release notes.)

Concerning the assignment of pull requests to releases, it will be possible to check that a pull request is not mentioned in the (Json format?) text files that list the release notes of earlier releases.

danielrademacher · 2021-02-24T19:13:12Z

dev/release_notes.readme.md

+  Thus the release notes are composed from all those merged pull requests that belong to the release in question (are assigned to the release branch or have a `backport-to-...-DONE` label for the release) AND do NOT have the label `release notes: not needed`.
+
+- For pull requests with the label `release notes: use title`, the text for the release notes is given by the title of the pull request.
+  For all other pull requests, the text for the release notes can be extracted from the pull request body.


This is not done automatically yet. The easiest solution should be the following one at the moment:
If the description for the release notes is short enough, it should be the title and the PR should include the label "release notes: use title". So we do not use the "Text for release notes:" section here.
If a description is too long for the title, e.g. because too many different topics are addressed, there should be a label: "release notes: dont use title" such that the script gives us this PR for manual viewing.

Maybe we can try to expand the script at the next GAP Days such that we also get the text from PRs. We could then try to mark the release notes text for the script using certain start and end strings. E.g. :
ReleaseNotesScript_StartPoint
Text for the release notes......
ReleaseNotesScript_EndPoint

danielrademacher · 2021-02-24T19:18:33Z

dev/release_notes.readme.md

+- Concerning the ordering, I think that somebody who reads the release notes of a new GAP version will be first interested in highlights, then in bugs which may affect one's computations (wrong results), then in removed functionality (which may break old private code), then in general improvements.
+
+  I think there is no way to satisfy all perspectives of what is most important, in particular concerning the `topic: ...` labels.
+  Note that `CHANGES.md` is just **one** way to present the changes, eventually we should put the source data (pull request number, release notes text, labels) into the GAP distribution, and provide a tool for evaluating the data inside a GAP session.


If we start a PR for this, we should add a link here.

I think that as soon as we have the files with the data list(s) and the GAP function (most likely in the dev directory of the main GAP directory), we should mention these files.

dev/release_notes.readme.md

danielrademacher · 2021-02-24T19:24:06Z

dev/release_notes.readme.md

+- Otherwise, try to find a short title that describes the pull request in the release notes; use appropriate maarkup in the title (e.g., backquotes for surrounding function names).  In this case, add the label `release notes: use title`.
+
+- Otherwise, make sure that the body of the pull request contains the relevant text below the line `## Text for release notes`.
+  (In the old workflow, the label `release notes: needed` should be added. I think this should be abolished.)


Instead of "release notes: dont use title" we can also use "release notes:needed" as suggested by Thomas here. Then we only have to delete the "release notes: added" label.

I think we need only two labels to define which pull requests appear in the release notes, and what is the text that is shown:

release notes: not needed for pull requests which shall not be mentioned in the release notes,

release notes: use title for pull requests which shall be mentioned in the release notes AND for which the text for the release notes is given by the title.

Then the pull requests without these labels are those which shall be mentioned in the release notes AND for which the text for the release notes can be found in the body.

Even with the automation, I think it is not realistic to expect that all PRs will always have the right labels and/or a good release not text (be it in the title or label). So I still expect that as we ramp up for a release, one or more dedicated people will go through PRs to "get them into shape" in that regard. For this process, I think it will still be useful to be able to distinguish between "unprocessed" PRs, and those which already have been taken care of (i.e. either have a good title and the "use title" label; or have a good text in the body, and some label indicating that; or are not needed for the release notes)

danielrademacher · 2021-02-24T19:27:54Z

dev/release_notes.readme.md

+- Otherwise, make sure that the body of the pull request contains the relevant text below the line `## Text for release notes`.
+  (In the old workflow, the label `release notes: needed` should be added. I think this should be abolished.)
+
+- Choose as many suitable (release notes relevant) labels as you want. Keep in mind that the pull request will appear just in the first applicable group of pull requests in `CHANGES.md`.


After discussing the last idea from #4257, maybe this can be added here.

danielrademacher · 2021-02-24T19:34:25Z

dev/release_notes.readme.md

@@ -0,0 +1,102 @@
+# How to produce release notes for GAP essentially automatically


Maybe we can make a short summary at the beginning of how to deal with PR in the future if somebody do not want to know the reason or explanations for the changes.

@danielrademacher Sorry, I do not catch the point. What do you suggest to add where in this file?

The text here is excellently written, summarizes all the important points from the GAP Days and provides a great overview for the future process. I just thought that for someone who would like to join the GAP community from scratch or maybe just want to start a PR, a short summary of how the labels should be dealt with would be helpful. When I think back to my first GAP Days, I was partially overwhelmed by all the processes and details. It was just an idea to possibly simplify the start.

@ThomasBreuer updated the .github/pull_request_template.md file and added such a brief summary, I think that does it? Other than that, I think people who submit PRs need not worry much about labels, it is people who merge PRs who need to worry about it (and perhaps request help from the PR authors, with instructions).

That said, I guess we still do need a text somewhere which summarizes which labels to use how, targeted at the group of people who want to / are supposed to review/triage/manage/merge PRs. But doing so goes beyond this PR, so I don't expect Thomas to add it here. But @danielrademacher feel free to open an issue requesting that and/or a PR starting such a file (it can be incomplete, and me and others can add more data to it in review comments for the PR, or after it got merged).

Related: issue #3381

Sorry, I didn't see the file .github/pull_request_template.md. The changes are great, that's exactly what I was thinking of. Thank you!

wilfwilson

I support what you've written here. I have only a few grammatical rermarks.

CHANGES.md

dev/release_notes.readme.md

CHANGES.md

olexandr-konovalov · 2021-02-24T21:13:05Z

dev/release_notes.readme.md

+
+- For pull requests with the label `release notes: use title`, the text for the release notes is given by the title of the pull request.
+  For all other pull requests, the text for the release notes can be extracted from the pull request body.
+  (The pull request template contains `## Text for release notes`, thus the relevant text is expected there; but where is the end of this text? We have to define a convention to mark the release notes text, then this text can be extracted automatically.)


Exactly. At that time, it was not envisaged that the we will automatically retrieve and process the PR description. We should be able to do this now, but a marker for the end of the text will be desirable.

Yes. I will extend the pull request template.

fingolfin · 2021-02-25T12:17:14Z

CHANGES.md

+### New packages redistributed with GAP
+
+
+### Updated packages redistributed with GAP
+


@alex-konovalov can you provide the missing data here?

We should perhaps also highlight the data fix in the smallgrp package, see release notes at https://github.com/gap-packages/smallgrp/blob/master/CHANGES.md

What about generally adding a link to the CHANGES.md files (if applicable) of updated and new packages?

Maybe also mention the new release of CTblLib (@ThomasBreuer what do you think?) and TransGrp which now provides representatives for all transitive permutation groups of degree at most 47 (@hulpke is that correct?)

for n in RecNames(old) do if not IsBound(new.(n)) then Print(old.(n).PackageName, " REMOVED\n"); continue; fi; if old.(n).Version <> new.(n).Version then Print(new.(n).PackageName, ": ", old.(n).Version, " -> ", new.(n).Version, "\n"); fi; od;

This currently gives me this (I can change the format which is being output easily)

GAPDoc: 1.6.3 -> 1.6.4 4ti2Interface: 2019.09.02 -> 2020.10-02 AutoDoc: 2019.09.04 -> 2020.08.11 Browse: 1.8.8 -> 1.8.11 CAP: 2019.06.07 -> 2020.10-01 CddInterface: 2020.01.01 -> 2020.06.24 ExamplesForHomalg: 2019.09.02 -> 2020.10-02 Gauss: 2019.09.02 -> 2020.10-02 GaussForHomalg: 2019.09.02 -> 2020.10-02 GeneralizedMorphismsForCAP: 2019.01.16 -> 2020.10-01 GradedModules: 2020.01.02 -> 2020.10-02 GradedRingForHomalg: 2020.01.02 -> 2020.10-02 HomalgToCAS: 2019.12.08 -> 2020.10-02 IO_ForHomalg: 2019.09.02 -> 2020.10-02 LinearAlgebraForCAP: 2019.01.16 -> 2020.10-01 LocalizeRingForHomalg: 2019.09.02 -> 2020.10-02 MatricesForHomalg: 2020.01.02 -> 2020.10-04 ModulePresentationsForCAP: 2019.01.16 -> 2020.10-01 Modules: 2019.09.02 -> 2020.10-02 MonoidalCategories: 2019.06.07 -> 2020.10-01 NConvex: 2019.12.10 -> 2020.11-04 NumericalSgps: 1.2.1 -> 1.2.2 PackageManager: 1.0 -> 1.1 PolymakeInterface REMOVED RingsForHomalg: 2019.12.08 -> 2020.11-01 SCO: 2019.09.02 -> 2020.10-02 SmallGrp: 1.4.1 -> 1.4.2 ToolsForHomalg: 2019.09.02 -> 2020.10-03 ToricVarieties: 2019.12.05 -> 2021.01.12 XMod: 2.77 -> 2.82 XModAlg: 1.17 -> 1.18 CTblLib: 1.2.2 -> 1.3.1 curlInterface: 2.1.1 -> 2.2.1 Digraphs: 1.1.1 -> 1.3.1 ferret: 1.0.2 -> 1.0.3 HAP: 1.25 -> 1.29 homalg: 2019.09.01 -> 2020.10-02 IRREDSOL: 1.4 -> 1.4.1 json: 2.0.1 -> 2.0.2 kan: 1.29 -> 1.32 matgrp: 0.63 -> 0.64 Polycyclic: 2.15.1 -> 2.16 PrimGrp: 3.4.0 -> 3.4.1 profiling: 2.2.1 -> 2.3 QPA: 1.30 -> 1.31 Semigroups: 3.2.3 -> 3.4.0 singular: 2019.10.01 -> 2020.12.18 TransGrp: 2.0.5 -> 3.0 Wedderga: 4.9.5 -> 4.10.0 AGT: 0.1 -> 0.2

Nice, saved my time, was about doing the same :) We may only count in the CHANGES the number of updated packages, like before, or put there this full list, I don't have a preference... Although adding it here will already have it ready for the release announcement.

So, seems we have all we need for the packages section.

TransGrp which now provides representatives for all transitive permutation groups of degree at most 47 (@hulpke is that correct?)
Yes, but if we mention this, we should credit this list of groups to Derek Holt.

@fingolfin could you please order packages alphabetically in the output?

@ThomasBreuer what I meant above asking whether to mention CTblLIb: there were many packages updated, but I thought of mentioning only essential updates in data libraries. Here we have SmallGrp and TransGrp worth mentioning already, and there is an update CTblLib: 1.2.2 -> 1.3.1 ready for the new release, so is there anything in it worth highlighting?

@alex-konovalov see the sorted list proposed in a comment below, and in the latest version of CHANGES.md in this branch

Concerning the question of package highlights, I think the only fair way to get this information would be to ask the authors/maintainers; I would not claim to say which new package versions do not have any highlight.
As for CTblLib, the list of news is quite long, I think that one short sentence in the GAP release notes of the kind "a few fixed bugs, new data, new functionality" will not be helpful.
(Would it make sense to support a new optional field in PackageInfo.g that contains a description of highlights, which can be added automatically to the GAP release notes?)

fingolfin · 2021-02-25T12:24:02Z

CHANGES.md

+<!--
+
+The following is an unstructured list of all those merged pull requests
+for GAP 4.12.0 until February 17th, 2021, that are relevant for release notes.
+The label "release notes: added" has already been attached to them.
+
+### New features and major changes


Reminder: when we backport this to stable-4.11, don't forget to remove this section

CHANGES.md

... colected by Paula, Daniel, and Thomas; currently unstructured

Thus the entries that are valid for the GAP 4.12.0 release notes are currently commented out in `CHANGES.md`. The entries for GAP 4.11.1 have been assigned to appropriate categories. The information on the new/updated packages is still missing.

... to the conventions described in issue gap-system#4257: Each pull request should appear only once in the release notes, according to a hierarchical ordering defined by its labels. (I have also added some markup to a few entries.)

What is **missing**, concerning the new file `release_notes.readme.md`: - definition of the convention which part of the pull request body defines the release notes text, - the script for extracting the set of relevant pull requests (number, text, labels), as a file in the `dev` directory - conversion of these data to a section of `CHANGES.md` (can be done with GAP) - decision how to deal with the labels `release notes: to be added` and `release notes: added` in the future - provide a Browse function for visualizing release notes data (I have a prototype)

- gap-system#3925 belongs to 4.12.0 not 4.11.1, - gap-system#4053 now belongs to `topic: julia`, not to `kind: bug: crash` - removed a superfluous "in"

fingolfin · 2021-02-26T12:28:27Z

CHANGES.md


 These changes are also listed on the
-[Wiki page](https://github.com/gap-system/GAP/wiki/gap-4.11-release-notes)
+[Wiki page](https://github.com/gap-system/gap/wiki/GAP-4.11-release-notes)


Actually, you know what? I'd remove this paragraph pointing to the Wiki completely. Then we also don't need to remember this Wiki page; we only used it in the past to help us coordinate the creation of release notes; but now that they are in a CHANGES.md within the GAP repository itself, there is no need, and being forced to update it just creates work with no obvious benefit?

This is a good idea.

fingolfin · 2021-02-26T12:30:04Z

dev/release_notes.readme.md

@@ -0,0 +1,102 @@
+# How to produce release notes for GAP essentially automatically


@ThomasBreuer updated the .github/pull_request_template.md file and added such a brief summary, I think that does it? Other than that, I think people who submit PRs need not worry much about labels, it is people who merge PRs who need to worry about it (and perhaps request help from the PR authors, with instructions).

That said, I guess we still do need a text somewhere which summarizes which labels to use how, targeted at the group of people who want to / are supposed to review/triage/manage/merge PRs. But doing so goes beyond this PR, so I don't expect Thomas to add it here. But @danielrademacher feel free to open an issue requesting that and/or a PR starting such a file (it can be incomplete, and me and others can add more data to it in review comments for the PR, or after it got merged).

Related: issue #3381

dev/release_notes.readme.md

and fixed a typo

CHANGES.md

fingolfin · 2021-02-26T15:50:58Z

CHANGES.md

+### New packages redistributed with GAP
+
+


According to @alex-konovalov there were no new packages. So either we drop this section ...

Suggested change

### New packages redistributed with GAP

or we say it, e.g.

Suggested change

### New packages redistributed with GAP

### New packages redistributed with GAP

There are no new packages in this GAP release.

I would omit the empty section, in the same way as we omit empty categories of pull requests. (If we say that there are no new packages, we should also say that no packages were left out that had been distributed before.)

There are definitely some updated packages in 4.11.1. If someone tells me which archive of packages will be used for the release, I can make a list and add it to CHANGES.md.

Sorry, I was wrong. There are new packages. Details to follow.

So, we had 152 packages in GAP 4.11.0, and 151 in the current merged packages archive, so we are down one package. Looking at homalg-project/homalg_project#221 and the history of revisions of https://github.com/gap-system/gap-distribution/commits/master/DistributionUpdate/PackageUpdate/currentPackageInfoURLList, I've restored this: @mohamed-barakat said we need to remove "PolymakeInterface and Convex from the future GAP distribution. They are now replaced by NormalizInterface and NConvex." Convex was withdrawn yet in GAP 4.11.0, and now the other package is withdrawn too. In the release notes we can say something like:

"Following the withdrawal of Convex in GAP 4.11.0 because of being superseded by NConvex, the PolymakeInterface had also been withdrawn. These two packages are now replaced by NormalizInterface and NConvex."

(I am not sure of there is a 1-to-1 replacement, or a combination of packages replaces another combination of packages).

@alex-konovalov I've uploaded a package-info.json.gz retroactively to https://github.com/gap-system/gap/releases/tag/v4.11.0 and compared it to one made in preparation for a new release. I did not see any new packages, but the PolymakeInterface package appears to have been removed?

The packages Convex and PolymakeInterface have been deleted some time ago from the homalg_project repository as well.

ThomasBreuer · 2021-02-27T06:28:27Z

@alex-konovalov I do not understand what you mean with

Maybe also mention the new release of CTblLib (@ThomasBreuer what do you think?)

A new version will become available, thus it has to be listed, or do we have a criterion of "omit package updates from release notes"?

ThomasBreuer · 2021-02-27T07:19:05Z

@alex-konovalov @fingolfin My first approximation of the packages section(s) for CHANGES.md would be as follows.

Packages no longer redistributed with GAP

PolymakeInterface: Following the withdrawal of the package Convex in GAP 4.11.0 because of being superseded by NConvex, the PolymakeInterface has also been withdrawn. These two packages are now replaced by NormalizInterface and NConvex.

Updated packages redistributed with GAP

4ti2Interface: 2019.09.02 -> 2020.10-02
AGT: 0.1 -> 0.2
AutoDoc: 2019.09.04 -> 2020.08.11
Browse: 1.8.8 -> 1.8.11
CAP: 2019.06.07 -> 2020.10-01
CddInterface: 2020.01.01 -> 2020.06.24
CTblLib: 1.2.2 -> 1.3.1
curlInterface: 2.1.1 -> 2.2.1
Digraphs: 1.1.1 -> 1.3.1
ExamplesForHomalg: 2019.09.02 -> 2020.10-02
ferret: 1.0.2 -> 1.0.3
GAPDoc: 1.6.3 -> 1.6.4
Gauss: 2019.09.02 -> 2020.10-02
GaussForHomalg: 2019.09.02 -> 2020.10-02
GeneralizedMorphismsForCAP: 2019.01.16 -> 2020.10-01
GradedModules: 2020.01.02 -> 2020.10-02
GradedRingForHomalg: 2020.01.02 -> 2020.10-02
HAP: 1.25 -> 1.29
homalg: 2019.09.01 -> 2020.10-02
HomalgToCAS: 2019.12.08 -> 2020.10-02
IO_ForHomalg: 2019.09.02 -> 2020.10-02
IRREDSOL: 1.4 -> 1.4.1
json: 2.0.1 -> 2.0.2
kan: 1.29 -> 1.32
LinearAlgebraForCAP: 2019.01.16 -> 2020.10-01
LocalizeRingForHomalg: 2019.09.02 -> 2020.10-02
matgrp: 0.63 -> 0.64
MatricesForHomalg: 2020.01.02 -> 2020.10-04
ModulePresentationsForCAP: 2019.01.16 -> 2020.10-01
Modules: 2019.09.02 -> 2020.10-02
MonoidalCategories: 2019.06.07 -> 2020.10-01
NConvex: 2019.12.10 -> 2020.11-04
NumericalSgps: 1.2.1 -> 1.2.2
PackageManager: 1.0 -> 1.1
Polycyclic: 2.15.1 -> 2.16
PrimGrp: 3.4.0 -> 3.4.1
profiling: 2.2.1 -> 2.3
QPA: 1.30 -> 1.31
RingsForHomalg: 2019.12.08 -> 2020.11-01
SCO: 2019.09.02 -> 2020.10-02
Semigroups: 3.2.3 -> 3.4.0
singular: 2019.10.01 -> 2020.12.18
SmallGrp: 1.4.1 -> 1.4.2
ToolsForHomalg: 2019.09.02 -> 2020.10-03
ToricVarieties: 2019.12.05 -> 2021.01.12
TransGrp: 2.0.5 -> 3.0
Wedderga: 4.9.5 -> 4.10.0
XMod: 2.77 -> 2.82
XModAlg: 1.17 -> 1.18

This format can be obtained from the above list list with the following GAP code.

SortBy( list, entry -> LowercaseString( entry[1] ) );
texts:= [];
for entry in list do
  name:= entry[1];
  info:= First( PackageInfo( name ), r -> r.Version = entry[2] );
  if info = fail then
    Error( name );
  fi;
  Add( texts, Concatenation( "[**", name, "**](", info.PackageWWWHome, "): ", entry[2], " -> ", entry[3] ) );
od;
res:= JoinStringsWithSeparator( texts, "\n" );;

How shall some hand-edited "package highlights" (SmallGrp, TransGrp) be mentioned?
Shall we add the names of package authors/maintainers?

mohamed-barakat · 2021-02-27T09:28:40Z

Updated packages redistributed with GAP

ToricVarieties: 2019.12.05 -> 2021.01.12

ToricVarieties have moved to @HereAround's meta-repository ToricVarieties_project

https://homalg-project.github.io/ToricVarieties_project/ToricVarieties/

ThomasBreuer · 2021-02-27T09:53:07Z

Yes, @mohamed-barakat, good point, the links should be produced from the PackageInfo.g information in the new package versions. (But where is the official package archive for that?)

cdwensley · 2021-02-27T10:11:45Z

@alex-konovalov The list appears to contain "XMod <https://gap-packages.github.io/xmod/> : 2.77 -> 2.82". Can version 2.83 not be included?

olexandr-konovalov · 2021-02-27T10:50:49Z

@cdwensley the table at https://github.com/gap-system/gap/wiki/Package-updates-status shows Xmod 2.83, it has been picked up. But the list above shows packages at https://github.com/gap-system/gap-distribution/releases updated some time before. That archive is better tested and, although it's tempting to flush package update system and include all latest, we should not do so in a rush. After the proper exercise with new release process, we should be able to release as often as before again, and then pick up new packages, in the meantime at least helping to more packages to restore their CI using GH actions and (maybe) even have new Docker-based package tests like we had before in Travis times...

CHANGES.md

to the list of updated packages in `CHANGES.md`, and corrected the link to the homepage of ToricVarieties

mohamed-barakat · 2021-02-27T12:06:18Z

Yes, @mohamed-barakat, good point, the links should be produced from the PackageInfo.g information in the new package versions. (But where is the official package archive for that?)

Everything should be here:

https://github.com/homalg-project/ToricVarieties_project/releases/

@alex-konovalov @HereAround

olexandr-konovalov · 2021-02-27T12:15:49Z

@mohamed-barakat I think @ThomasBreuer asks not about your package archive, but for merged package archives (we also call them bootstrapping archives) at https://github.com/gap-system/gap-distribution/tags used for the release. Otherwise they may be out of sync.

mohamed-barakat · 2021-02-28T10:20:32Z

@mohamed-barakat I think @ThomasBreuer asks not about your package archive, but for merged package archives (we also call them bootstrapping archives) at https://github.com/gap-system/gap-distribution/tags used for the release. Otherwise they may be out of sync.

I don't understand the difference, maybe because by now we provide all of our package archives which are picked up by the GAP distribution system as GitHub releases. Martin is probably using a different mechanism (see homalg-project/PackageJanitor#64).

In any case, according to ToricVarieties/PackageInfo.g the file PackageInfo.g should be located at

https://homalg-project.github.io/ToricVarieties_project/ToricVarieties/PackageInfo.g

fingolfin · 2021-02-28T10:43:02Z

@mohamed-barakat the difference is that there is a delay between when a package is released, and when we pick it up for redistribution in the GAP package distribution (which is also used as "bootstraping archive" but I's not use this term except when talking about the GAP build system).

in addition to the delay (which can be days or weeks, depending on when the update job runs), we may also reject package updates, when they fail to validate, or roll back to older versions if the new version introduces regressions in the GAP test suite.

mohamed-barakat · 2021-02-28T10:52:30Z

I see, thanks Max.

fingolfin

I am going to merge this now; the release notes look good; and release_notes.readme.md can still be edited later if needed.

fingolfin reviewed Feb 16, 2021

View reviewed changes

CHANGES.md Outdated Show resolved Hide resolved

ThomasBreuer force-pushed the TB_release_notes branch from 0578a6f to 46011df Compare February 17, 2021 16:00

ThomasBreuer changed the title ~~some release notes entries for 4.11.1 or 4.12.0~~ some release notes entries for 4.11.1 Feb 18, 2021

ThomasBreuer mentioned this pull request Feb 23, 2021

Simplify the creation of release notes #4257

Closed

fingolfin reviewed Feb 23, 2021

View reviewed changes

CHANGES.md Outdated Show resolved Hide resolved

fingolfin reviewed Feb 23, 2021

View reviewed changes

CHANGES.md Outdated Show resolved Hide resolved

danielrademacher reviewed Feb 24, 2021

View reviewed changes

wilfwilson reviewed Feb 24, 2021

View reviewed changes

olexandr-konovalov reviewed Feb 24, 2021

View reviewed changes

fingolfin reviewed Feb 25, 2021

View reviewed changes

CHANGES.md Outdated Show resolved Hide resolved

wilfwilson mentioned this pull request Feb 25, 2021

Make bin/BuildPackages.sh compatible with more systems (in particular, ones without wait -n)? #4289

Closed

ThomasBreuer added 6 commits February 25, 2021 22:26

some release notes entries for 4.11.1 or 4.12.0

f065b95

... colected by Paula, Daniel, and Thomas; currently unstructured

adjusted the entries for GAP 4.1.11 in CHANGES.md

9d1a2be

... to the conventions described in issue gap-system#4257: Each pull request should appear only once in the release notes, according to a hierarchical ordering defined by its labels. (I have also added some markup to a few entries.)

address proposed corrections

8cc22be

- gap-system#3925 belongs to 4.12.0 not 4.11.1, - gap-system#4053 now belongs to `topic: julia`, not to `kind: bug: crash` - removed a superfluous "in"

tried to address the comments

98ca5c6

ThomasBreuer force-pushed the TB_release_notes branch from 6db0559 to 98ca5c6 Compare February 25, 2021 21:28

wilfwilson mentioned this pull request Feb 26, 2021

Enable wider compatibility for bin/BuildPackages.sh --parallel #4291

Merged

8 tasks

fingolfin reviewed Feb 26, 2021

View reviewed changes

removed the link to the wiki page

3453b12

and fixed a typo

ThomasBreuer force-pushed the TB_release_notes branch from 35517d4 to 3453b12 Compare February 26, 2021 12:45

fingolfin reviewed Feb 26, 2021

View reviewed changes

CHANGES.md Show resolved Hide resolved

fingolfin reviewed Feb 26, 2021

View reviewed changes

updated a formulation according to gap-system#4290

32f40b9

ThomasBreuer force-pushed the TB_release_notes branch from 54c707e to 32f40b9 Compare February 26, 2021 22:40

added changed packages to CHANGES.md

aefa033

olexandr-konovalov reviewed Feb 27, 2021

View reviewed changes

CHANGES.md Show resolved Hide resolved

added introductory text

cffe034

to the list of updated packages in `CHANGES.md`, and corrected the link to the homepage of ToricVarieties

fingolfin approved these changes Feb 28, 2021

View reviewed changes

fingolfin merged commit b60b8b1 into gap-system:master Feb 28, 2021

		@@ -0,0 +1,102 @@
		# How to produce release notes for GAP essentially automatically

		### New packages redistributed with GAP


		### Updated packages redistributed with GAP

some release notes entries for 4.11.1 #4256

some release notes entries for 4.11.1 #4256

Conversation

ThomasBreuer commented Feb 16, 2021 • edited Loading

codecov bot commented Feb 16, 2021 • edited Loading

Codecov Report

fingolfin commented Feb 23, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wilfwilson left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ThomasBreuer Feb 27, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ThomasBreuer commented Feb 27, 2021

ThomasBreuer commented Feb 27, 2021 • edited Loading

Packages no longer redistributed with GAP

Updated packages redistributed with GAP

mohamed-barakat commented Feb 27, 2021 • edited Loading

Updated packages redistributed with GAP

ThomasBreuer commented Feb 27, 2021

cdwensley commented Feb 27, 2021 via email

olexandr-konovalov commented Feb 27, 2021

mohamed-barakat commented Feb 27, 2021

olexandr-konovalov commented Feb 27, 2021

mohamed-barakat commented Feb 28, 2021

fingolfin commented Feb 28, 2021

mohamed-barakat commented Feb 28, 2021

fingolfin left a comment

Choose a reason for hiding this comment

ThomasBreuer commented Feb 16, 2021 •

edited

Loading

codecov bot commented Feb 16, 2021 •

edited

Loading

wilfwilson left a comment •

edited

Loading

ThomasBreuer Feb 27, 2021 •

edited

Loading

ThomasBreuer commented Feb 27, 2021 •

edited

Loading

mohamed-barakat commented Feb 27, 2021 •

edited

Loading