Closed algomaster99 closed 1 year ago
Looks good. One small thing, could we use the full hashes instead of the short ones? In theory, the short ones can be ambiguous in the future.
Projects marked with + have tagged commits that do not belong in the history of the project. Maybe we could take those commit's parents instead?
Parent should be fine.
I fetched the releases primarily from maven central. In their corresponding GitHub repository, those projects have much later releases. What should be considered? Please note that I did not consider GitHub releases in the first place because I wanted to focus on the release of one submodule so I turned to maven central instead.
I have no hard opinion on this, either the newest release or the release close to the depclean dataset is fine for me.
One small thing, could we use the full hashes instead of the short ones? In theory, the short ones can be ambiguous in the future.
When reading, yes that is possible. However, the links are okay so when clicking, the commit cannot be ambiguous.
I have added commits according to the latest releases. There are two decisions we need to make.
Projects marked with
+
have tagged commits that do not belong in the history of the project. Maybe we could take those commit's parents instead?I fetched the releases primarily from maven central. In their corresponding GitHub repository, those projects have much later releases. What should be considered? Please note that I did not consider GitHub releases in the first place because I wanted to focus on the release of one submodule so I turned to maven central instead.
I am also thinking to exclude modules that are not maintained anymore (they do not exist in the source code as of 01/01/23) solely because they might cause dependency resolution failures when we analyze them.
@MartinWitt @monperrus what do you think? .