Comments (12)
The tagged commit seems to be 19f0abd
from electron.
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 git archive
generated one) with zcat package.tar.gz | git get-tar-commit-id
.
from electron.
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
from electron.
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:
- npm version tags (once it's live on npm, it's actually live)
- github releases (not tags), the tag is made quite early during the release process, an associated release is only published as the final step
- Operate off of our canonical Source Of Truth for electron releases. https://releases.electronjs.org (or the JSON feed https://releases.electronjs.org/releases.json). Things only show up in that feed when they've been published.
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
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
from electron.
Thanks for the response. Just a couple points:
- I did switch from starting test releases when a tag landed to not launching anything until it lands as an announcement on releases.elctronjs.org. That is not as infallible as you suggest though, twice now releases have been posted there only to later disappear with no explanation.
- The GH Releases system has some glitches too, it is not uncommon for a release to get missed entirely there, and other times they get labeled as pre-releases and the label never removed even long after the release is posted on the website and even the next release lands.
- Deleting half-baked artifacts is one thing, but yanking the tag with no visible explanation and eventually re-posting the same number is definitely an anti-pattern.
from electron.
That is not as infallible as you suggest though, twice now releases have been posted there only to later disappear with no explanation.
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.
other times they get labeled as pre-releases
Not sure what this is referring to specifically, but we label and leave all "alpha" and "beta" releases as pre-release
. There shouldn't be any stable x.y.z
versions tagged as "pre-release" on github.
Deleting half-baked artifacts is one thing, but yanking the tag with no visible explanation and eventually re-posting the same number is definitely an anti-pattern.
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.
from electron.
@brjsp You can usually identify what commit a tarball is from (assuming it is a
git archive
generated one) withzcat package.tar.gz | git get-tar-commit-id
.
@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 electron/
subdirectory. We just download everything using gclient and remove the irrelevant libraries and binary blobs afterwards (since we would have to do that anyway) — the git metadata do not survive that process.
from electron.
29.1.1
is one tag that hit the releases website and then later wasn't there for an extended time. I had a bit of an exchange with a RISC-V packager for an Arch Linux port about it and tried to defend it being there when he couldn't find it, and then eventually force refreshed my browser on the announcement page and got a 404. The tag had lived on Git for at least a couple days, then was gone for about a week at least (Mar 1st–6th) before coming back with lots of new content. At the time that happened I remembered it having happened before but I do not have a record of what tag it was.
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.
from electron.
@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.
from electron.
regenerates this list of sources that we can checkout using a sources cache that is available across builds
@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 keeplibs
) and our policy requires us to actually keep a copy of the source, not just provide hashes.
(Also, our diff view on OBS seems not to like multiple versioned tarballs).
from electron.
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 keeplibs
list. I might review that as a way to trim our source setup.
from electron.
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
@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)
from electron.
Related Issues (20)
- [Bug]: `screen.getAllDisplays()` and `desktopCapturer.getSources()` order no longer matches (29.3.2, 30.0.2)
- [Bug]: `desktopCapturer` thumbnails not respecting `thumbnailSize`, always low-res (29.3.2) HOT 1
- [Bug]: Calling preventDefault on BrowserWindow close event still destroys BrowserViews' webContents HOT 1
- [Feature Request]: Support webp format in NativeImage class [totoWEBP()]
- [Bug]: `fs.readdir` does not work correctly with files that contain umlauts HOT 3
- [Bug]: showMessageBox ignores abort signal if BrowserWindow is not provided on MacOS HOT 2
- [Bug]: Do not working portable version HOT 1
- [Feature Request]: Computer shutdown/sleep request HOT 1
- [Bug]: WebContentsView preload.js events fullscreenchange not work HOT 1
- [Bug]: fs.createWriteStream had a bug and has been fixed on v18.20.0, v20.12.0, and v21.7.1. I wonder if we can accelerate the releases on Electrons that depend on newer Node. HOT 1
- [Feature Request]: Opening On-Screen Keyboard in Electron.js Application. HOT 1
- [Bug]: 'suspend' and 'resume' events not emitted by powerMonitor HOT 4
- [Feature Request]: Allow handler in app.on("open-url", handler) to choose whether to activate the app or not
- Popup handling in BrowserViews doesn't work with WebContentsView HOT 2
- [Feature Request]: Add possibility to change DevTools font HOT 1
- [Bug]: incorrect behavior of the WebContentsView when the electron app window is inactive
- [Bug]: BrowserWindow.fromWebContents does not work with WebContentsView WebContents HOT 2
- [Bug]: WebContentsView has no ability to set which view is "on top" when overlapping HOT 1
- [Bug]: View.addChildView can be used to add the same view multiple times, causing crash
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from electron.