New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stop removing tags from your repo #42025
Comments
The tagged commit seems to be 19f0abd |
Yes, very much the same complaint here. I am the packager for all the official Arch Linux packages. The practice of re-tagging on this repo has cost me quite a bit of time in the past and is a regular source of frustration. I've complained about it in the past too, but it keeps happening. It would be much appreciated if a different workflow could be setup. If a release goes wrong and you want to get some extra commit it, just tag a new minor version. Or figure out a way to run your release checks privately without pushing the tag to the public repo until you know it is good to go. @brjsp You can usually identify what commit a tarball is from (assuming it is a |
alpine linux package maintainer here, i think i haven't noticed it myself before on this repo, actually. though i think i'm also the only one here only tracking one branch at a time |
Hey folks, appreciate there is a disconnect here. Unfortunately changing how we do tags / releases is not a thing that would be easy to do, even if we wanted to do it. For clarity, if at any point the release process fails in an unrecoverable way we initiate a "clean up" that removes all our temporary artifacts and deletes the tag completely. This, along with the rest of our release process, is fully automated. If you're looking for a clear indication of "when an electron release is actually released" you can operate off of either:
Just want to note here, this isn't a thing we actively support / know y'all are doing. So to be fair, it's not like we're doing it deliberately |
Thanks for the response. Just a couple points:
|
I'd be interested in version numbers for these cases, we keep detailed release logs and it shouldn't be possible for a release to show up on releases.electronjs.org and then later be removed 🤔 I can chase down why that is occurring.
Not sure what this is referring to specifically, but we label and leave all "alpha" and "beta" releases as
I don't necessarily disagree, just noting how things currently work and that changing them is unlikely to be a thing. What we can do is make sure there is something that y'all can use as a source of truth, I believe it is releases.electronjs.org but if that is exhibiting similar conditions then that might be something we have to look into as noted above. |
@alerque We don't do “use git archive and add a separate tarball with vendored stuff” for Electron. It's impractical as the bulk of the code is patched Chromium, and the “main” repo lives in an |
Is there a public build log somewhere that we could check to see if a release was pulled and see what commit SHA was originally tagged? That would be quite useful for us distro packagers to review. |
@brjsp Understood, and yes that would loose the meta data (c.f. my request for a log of yanked tags and their commit hashes), and yes I understand why you've taken that route to handling the sources. We did something similar for a long time, and now take a bit different tactic: We scripted something up that iterates through the sources manifest for a given release and finds all the pinned commits for vendered sources, then regenerates this list of sources that we can checkout using a sources cache that is available across builds and even Electron versions to save bandwidth and local storage while still tracking hashes for all our input sources. |
@alerque Looking at that list, this is something we (openSUSE) very much do not want to do. Half of these libraries are unused in fact (grep our script for (Also, our diff view on OBS seems not to like multiple versioned tarballs). |
Understood, I wasn't suggesting you copy the approach. There are definitely pros and cons to each possible way, and we've tried quite a few for this project. This is the best suited to our build tooling so far. And no Arch does not keep archived copies of source inputs like OpenSUSE, Debian, and a few others do. We do have hashes not jsut for the sources but for every file in the sources too, and this is useful for comparing with the sources being used in other distros. See e.g. electron30 on whatsrc.org. Thanks for the pointer on your |
@selfisekai At openSUSE we also track only one branch (we neither have resources for maintaining multiple versions nor has such a need come up yet). Though i rather tend to follow https://3rdpartysource.microsoft.com/ for the question of “what is the latest stable version” rather than github, since VSCode (the most complicated app we ship) likes to break in unexpected ways (I recall 15 and 23 being problematic in that — both are Electron branches that bumped the Node major) |
Hello. I maintain the electron package in openSUSE.
Yesterday you have added a
v29.3.2
tag to the repository. It was live long enough for me to download the tarball and start preparing the release.It is impossible now to verify which commit the source code corresponds to, because you have deleted the tag. I managed to catch this before publishing the new version but you are wasting time of me, the openSUSE release team, and possibly my counterparts in other distros. I'm going to tag them just to alert them to this bad practice of yours: @alerque @selfisekai @tagattie
The text was updated successfully, but these errors were encountered: