search

noloader / cryptopp-cmake

CMake files for Crypto++ project
BSD 3-Clause "New" or "Revised" License
92 stars 67 forks source link

GitHub release action and names/tags #95

Closed noloader closed 2 years ago

noloader commented 2 years ago

A GitHub bot sent an email saying it released with the name CRYPTOPP_8.7.0. That does not follow our convention, which uses underscores. For example, we use CRYPTOPP_8_6_0.

Can we get that fixed, please?

In the future, lets avoid having bots do this. Keep a human involved in releasing and signing.

abdes commented 2 years ago

Noted. That was a mistake from my side not the bot. The bot only activates when I push a release tag, and I pushed it with the wrong convention. It is being fixed and will reflect in the next minutes.

The bot only creates a release after the release tag of the format CRYPTOPP_M_m_p is pushed, and what it does is simply create a release for that tag (ONLY after all builds succeed and all tests pass) and then attaches the artifacts to it.

After that I manually edit the release notes and validate the release.

abdes commented 2 years ago

Done.

Please check the release at: https://github.com/noloader/cryptopp-cmake/releases/tag/CRYPTOPP_8_7_0

The GitHub Actions logs at: https://github.com/noloader/cryptopp-cmake/actions/runs/2907309149

If this is good, please close the issue.

abdes commented 2 years ago

By the way, how are we supposed to handle a situation where after release, we discover a bug in the cmake scripts? Should we release a new version, or re-release the same version? If a new version, what should be the tag? @noloader

noloader commented 2 years ago

@abdes,

Maybe you can take over Cmake gear? Create a GitHub repo called cryptopp-cmake. You run it. I'll point all documentation to your GitHub.

I'll delete my cryptopp-cmake since you are running the official version.

(It is important to have a single source of truth. If you take this over, I have to delete mine so users know where to find the one true Cmake and users are not confused).

What do you think?

noloader commented 2 years ago

@abdes,

how are we supposed to handle a situation where after release, we discover a bug in the cmake scripts? Should we release a new version, or re-release the same version? If a new version, what should be the tag?

Well, your primary control to avoid the situation is testing. Be careful of moving too fast before you can test a bunch of platforms and compilers. From my experience, Cmake is very buggy and you need to test on AIX, BSD, Cygwin, MinGW, Linux, OS X, Solaris and Windows. You also need to test CPUs and ABIs like armel, armhf, arm64, powerpc, powerpc64el, x86, x86_64 and sparc. I have not had the time to test and fix all the bugs on those platforms. Hence the reason CRYPTOPP_8_7_0 was not released.

If you are just testing on Linux x86_64 or Windows, then you are going to have a lot of trouble maintaining something that's ready for the world. Users are going to experience a lot of pain, and it is going to create lot of extra work for yourself.

If a release is botched and it happened recently (like within the last week), then delete the broken release and release a new release. I had to do this with Crypto++ 5.6.4 a few years back. OpenSSL did the same a few years ago. My thinking is, a re-release will cause a few users harm in the near term. But in the long run the re-release will benefit most users.

If a release is botched and it is discovered later (like 30 or 60 days), then check-in the fix and point people to the fix. It is likely something in this case is unusual or a corner case since folks did not experience it immediately. The fix will be picked up in the next release cycle.

abdes commented 2 years ago

Maybe you can take over Cmake gear? Create a GitHub repo called cryptopp-cmake. You run it. I'll point all documentation to your GitHub.

I'll delete my cryptopp-cmake since you are running the official version.

(It is important to have a single source of truth. If you take this over, I have to delete mine so users know where to find the one true Cmake and users are not confused).

What do you think?

I think the disruption would be too big. I have no issue doing the maintenance on the current repo, even though it is owned by you. Requesting everyone to redo their forks, change their submodules, change their scripts, etc... is really not a good idea and would just frustrate a number of users. And by the way, the single source of truth right now is this repo, I do not have an alternate one, and even myself, I use this repo in my projects, not even my fork...

For the release cycle, I understand your thinking, and that would definitely work for botched releases. My concern was more for the long time between the crypto++ releases. I was thinking to add a letter behind the tag, indicating that the version is still for that specific crypto++ release, but some enhancements/fixes were made for cmake build only, not for crypto++. So people can grab enhanced cmake scripts, and know reliably which version of crypto++ is being pulled.

For example: CRYPTOPP_8_7_0_a, CRYPTOPP_8_7_0_b, etc...

For leading edge users, they can just grab the master tag and always be at the top of the branch.

What do you think?

abdes commented 2 years ago

Also, as we have seen last week, people only start testing the new release when it is tagged, not when the change is implemented in master... so somehow, we'll have to release it and then discover some bugs/issues and then fix them after release.

mouse07410 commented 2 years ago

In my opinion, based on the fact that several (many?) people use automated tools to track and install updates - is a release is botched, you must update/increase the version/tags.

I've had a problem when the system could not install an updated version that carried the same tags as the previous one - because, of course, its hash value did not match the previous one.

On Aug 23, 2022, at 06:58, Abdessattar Sassi @.***> wrote:



Also, as we have seen last week, people only start testing the new release when it is tagged, not when the change is implemented in master... so somehow, we'll have to release it and then discover some bugs/issues and then fix them after release.

— Reply to this email directly, view it on GitHubhttps://github.com/noloader/cryptopp-cmake/issues/95#issuecomment-1223902920, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABNGF6LE3EU5SNPOFOZ2S4TV2SVFZANCNFSM57IXFLQQ. You are receiving this because you are subscribed to this thread.Message ID: @.***>

abdes commented 2 years ago

Repo rolled back, and this issue is no longer applicable here. It is open for discussion at https://github.com/abdes/cryptopp-cmake if needed.

@mouse07410