At [company x] someone wrote a starter guide that tells developers to create a "production", "staging" and "dev" branch for any new repo. We have tons of repositories that follow this pattern.
For many of them, each branch has taken of its own life and could be considered its own completely different codebase. It's a nightmare to manage and it confuses developers on a regular basis.
Don't do this.
If you want to deploy different versions of your software in different environments, use SEMVER and git tags. Don't create 1 branch per environment...
I have since edited that starter guide and crossed out this recommendation.
But then I also find I need to train devs on how git actually works and how to use git properly because I find that only about 10% of devs actually understand git. But it works out best for everyone once all the devs understand git, so generally most devs appreciate it when someone is willing to teach them the ins and outs (but not all devs appreciate it before they learn it properly though).
As always though, it's trade offs.
Seems you have bigger process issues to tackle. There's nothing inherently wrong with having per-env branches (if one thing, it's made harder by git being so terrible at branching in the general/long lived case, but the VCS cannot alone be blamed for developers consistently pushing to inadequate branches).
Interesting. What's wrong with branching in git?
OTOH, git branches are pointers to one single commit (with the git UI tentatively converting this information sometimes into "that commit, specifically" or sometimes as "all ancestors commits leading to that commit", with more or less success and consistency).
Where it matters (besides fostering good/consistent UX) is when you merge several (topological) branches together: git won't be able to tell if you just merged A into B or B into A. Although the content is identical at code-level, the semantic/intent of the merge is lost. Similarly, once the head has progressed so much ahead and your history is riddled with merges, you can't tell from the DAG where the individual features/PR/series start and end. This makes bisecting very hard: while hunting down a regression, you would rather avoid checking-out mid-series commits that might break the build, and instead stick to the series boundaries. You can't do that natively with git. That also makes maintaining concurrent versions unnecessarily difficult, and many projects are struggling with that: have you seen for instance Django¹ prefixing each and every commit with the (long-lived) branch name? That's what you get with git while most other VCSes (like Mercurial, my preference) got right from the start.
That's why git also offer tags. Tags are immutable.
That's an important distinction.
tl;dr you lose some semantic (and practical capabilities, UX and effectiveness) when you don't capture branch information at commit-level
There is when you stop thinking in terms of dev, staging and prod, and you realize that you might have thousands of different environments, all named differently.
Do you create a branch for each one of them?
Using the environment name as branch name is coupling your repository with the external infrastructure that's running your code. If that infrastructure changes, you need to change your repository. That in itself is a cue it's a bad idea to use branches this way.
Another issue with this pattern is that you can't know what's deployed at any given time in prod. Deploying the "production" branch might yield a different result 10 minutes from now, than it did 25 minutes ago. (add to the mix caching issues, and you have a great recipe for confusing and hard to debug issues)
If you use tags, which literally are meant for that, combined with semver (though not necessarily a requirement, but a strong recommendation), you decouple your code and the external environment.
You can now point your "dev" environment to "main", point staging to ">= v1.25.0" and "prod" to "v1.25.0", "dev-alice" to "v2.0.0", "dev-john" to "deadb33f".
When you deploy "v1.25.0" in prod, you _know_ it will deploy v1.25.0 and not commit deadb33f that so happened to have been merged to the "production" branch 30 seconds ago.
Tools are just there, it's people who misuse them. If devs at company x are incapable of understanding that you shouldn't be cooking an omelette in the meeting room, to be honest that's on the dev, not on the separation of concerns that was put there for them.
Probably what's missing there is training to set the expectations, policing on their actions, and a soft reprimand when the typical first time mistake is done. But if the metaphorical rooms have no indicators, no name tags, and no obvious usage guidelines, because no one bothered to set them up, then yeah expect board meetings to end up happening in the kitchen.
Absolutely. And it doesn't help when people write guides actively encouraging mis-using tools
There are multiple valid branching strategies. Your recommended strategy works well[0] with evergreen deployments, but would fail hard if you intend to support multiple release versions of an app, which happens often in the embedded world with multiple hardware targets, or self-hosted, large enterprise apps that require qualification sign-offs.
0. Semver uas many issues that I won't repeat here, mostly stemming from projecting a graph of changes onto a single-dimension.
https://www.digitalocean.com/community/tutorials/customizing...
I don't have experience in this world, indeed.
But isn't "multiple release versions of an app" just "one application, with multiple different configurations"? The application code is the same (same version), the configuration (which is external to the application) is different.
Your build system takes your application code and the configuration as input, and outputs artifacts for that specific combination of inputs.
That would be nice (and evergreen), but that's not always the case. It's common to have different versions of the app released simultaneously, with different features and bugfixes shipped.
Think of Microsoft simultaneously supporting Windows 10 and 11, while still releasing patches for XP: they are all individual OSes that share some common code, but can't be detangled at build times[1]
The customer will be reluctant to upgrade major versions due to licensing costs and risk if breakage (your code, or their integrations), but still expect bugfixes (and only bugfixes) on their deployed versions, which you're contracted to provide. Using the evergreen approach.
I'm not convinced using build flags to manage which code is shipped is superior to release branches, I fall on the side of release branches because using bisect is invaluable.
1. I suppose as long as the build system is turing complete, one could hypothetically build Windows XP, 7, 8, 10 and 11 off the same codebase using flags. I would not envy that person.
and it also says that it runs without those runtime dependencies, except that the experience will be degraded. so the question is how degraded, and what will it take to fix that?
The new default is that background windows become slightly transparent.
https://www.dropbox.com/scl/fi/8o0tmimx09pwak2h0lfi0/fynedes...
Ready for a wayland support to begin after the next release!
Having the desktop environment, and given Go's stance on dynamic linking (and kind of abandoned plugin package), replace the dynamic behaviours in Oberon and Inferno commands and application extensions, with D-Bus or net/rpc.
However given the state of desktop fragmentation, most likely it wouldn't be worth the effort, only to get the feeling how it could be like.
We are integrating an app editor into FyshOS which (although now renamed and at https://apptrix.ai) can be seen in an old video as a preview: https://youtu.be/XXmDmn-et4E?si=5n1Ao-V6dKurXzS6 (mostly from 15:30 in)
There is indeed a promising alternative to Go plugins which - very similar to the Oberon System - directly loads and runs the object files generated by the compiler: https://github.com/pkujhd/goloader.
Tear free is provided by the compositor and the fractional scaling was never impossible with X it just had to be coded into the toolkit and most could not be bothered. Fyne has always supported fractional scaling and I think Enlightenment does too.
However if you want to try it in development mode you can “make embed” to try it in an embedded X session.
I see they work on full Wayland support, and targeting to do it in v5.0. What's the ETA? Last release was 1.5 year ago!
> The 0.4 branch of releases marks the end of X11 native implementations as we will begin the move to Wayland (and XWayland) for 0.5. > https://github.com/FyshOS/fynedesk/releases
When it’s ready, and faster if you help.
If someone randomly comes up to you and offers you an apple with a rotten spot and you say "No thanks, there's a big rotten spot" would you expect them to scold you for being entitled and looking a gift horse in the mouth? _They_ came up to _you_ offering an apple!
you don't have to produce my style, and i don't have to buy your clothes, but it's good to talk about our preferences so you have a better idea of the potential market.
Clearly there are stronger plausible interpretations of the GP. Following that guideline tends to prevent getting caught in snags like this little subthread, making discussion more enjoyable for everyone.
(I don't mean this as a criticism! it's just a nice case to comment on because it's particularly clear.)
from the Author
Which is a damn shame, because window managers are where some of the greatest innovation is happening.
innovation is happening with compositors too.
Ideally we will support both through the transition but unclear at this time.
It's support for CJK input is also basically broken with no chance of ever getting revived.
Our best bet on a solid Linux gui lies with XLibre.
However, saying that, a gui written in Go has very little reason to exist, because we already have excellent GUIs written in lower-level languages.
If there is anything Linux doesn't lack it it's desktops.
For those who want a fast to learn and use higher level language for this Go is a great tool and there are great projects out there. Two of them in the top 10 for all cross platform beating out a lot of other languages (no presence of GTK or Qt up that high... https://ossinsight.io/collections/cross-platform-gui-tool/)
For me I prefer higher level code and tooling wherever possible. Building this has been blazingly fast compared to previous window managers I have worked on.
exactly this.
go actually strikes a balance of being one of the few high level languages that can compile directly to binary. there are not many languages that can do that. common lisp, erlang, o'caml and maybe red are a few others that i am aware of. there are probably a few more that are less popular that i don't know.
for me high level implies at least automatic memory management and high level data types.
Does Fyne have bindings to other languages? A search for fyne python gave some hilarious AI slop from Gemini suggesting pip install fyne, but the fyne python package is something completely different and unrelated. The nice thing about GTK is it can be used from virtually any language (QT a bit less so but still a lot)
Why would I want something "fast to learn"? That sounds like one of the most ridiculous arguments when choosing a tool to master ever. On the level of "I chose this university because it was walking distance from home".
I'm choosing a tool I'm going to be using for the next 40 to 50 years. Whether it takes a month or a year to learn makes no difference whatever.
I want a tool language which is widely portable, so that I could run my programs without rewriting them on as many machines I own as possible.
I also want them to run as fast, as possible, because I want to run many useful programs on moderate hardware.
I want to be able to use as many libraries and external utilities as possible, because nobody knows when I might need them.
It should also work without internet, because who knows when exactly the government is going to cut the wire.
These core features are what I b would not even consider a language at all. The rest is bells and whistles. Nice to have, but completely optional.
>Two of them in the top 10 for all cross platform
I've never heard about any libraries from that list. In any case they seem like tools to write webpages, not tools to write desktop software.
You say that as if it's a good thing. The fact that our platforms depend on C and C++ is not a feature, it's a bug.
For example the modules on the panel or desktop are basically just functions that return a `fyne.CanvasObject` so it's basically just like making a panel in a Fyne app :).
It does run, but I feel like it's more of a prototyping tool, or a tool for building internal apps. It's kinda slow, graphically inconsistent with the rest of Android, and it has little to no support for features like foreground services, the camera, and more.
I really hope they can improve, but with limited resources and funding, and such a wide scope, I'm not sure if they will ever be ready for more complex projects. In any case, best of luck to the devs!
Camera and services are coming in another release - work has begun.
It's amazing what has been done with virtually no funding - if anyone would consider sponsoring then truly incredible things could be delivered :).
The best I can find is the parent Github account, which has two users: https://github.com/FyshOS
We are always looking for sponsorship and of course commercial partnerships would be pretty cool too!
Basically the project came from the Fyne community because we can build all GUI apps so fast now that it was a shame not to have a desktop environment with the same benefit :).
I wanted a modern alternative to exist that was approachable and fun. And once we have met existing systems we can start to exceed them ;).
Keep up the good work!
Dont know what the state is but they work on it
Monocrome icons, tiny scrollbars, label buttons, Material design at its finest. Nothing new here. /s
koeng•4mo ago
gigatexal•4mo ago
I bet it’s smooth given how concurrent friendly Go is with channels and go routines etc.
munchlax•4mo ago
Aren't all computers plenty fast enough now?
gigatexal•4mo ago
shmerl•4mo ago
Someone could totally make it do everything in a single thread and not think about that, which would be pretty bad.
winrid•4mo ago
shmerl•4mo ago
nasretdinov•4mo ago
wiseowise•4mo ago
munchlax•4mo ago
They run XFCE just fine.
Twirrim•4mo ago
pjmlp•4mo ago
robinsonb5•4mo ago
(I'm not kidding - the tight coupling of quadrature-based mouse counters and hardware sprite mouse cursor - bypassing all the wireless, serial / PS/2 / USB encoding and decoding we have today - and on-screen gadgets being drawn and redrawn in the input subsystem's context without messages having to trickle through a ten foot long pipeline of frameworks and UI toolkits, all gave a sense of immediacy, of "having the computer's full attention", that's rare to find in today's world of janky semi-functional web apps.)
matttproud•4mo ago
I imagine FyneDesk is plenty fine for what it is doing in comparison.
radicaldreamer•4mo ago
ffsm8•4mo ago
Isnt it only the _design_ of stage manager somewhat resembles some design choices by project looking glass?
this design has also been adopted by the other OS's like windows+tab has previously (in win7 days) created a similar looking view - though it no longer looks like it nowadays.
bestham•4mo ago
heavyset_go•4mo ago
Looking Glass-like switchers are still available in Plasma
blauditore•4mo ago
Classic Apple.
p_l•4mo ago
andydotxyz•4mo ago
FyneDesk aims to compete on performance with the light weight window managers whilst offering the rich experience of complete desktops.
We are close on performance in most areas, once Fyne v2.7.0 is out we will do a new release which is going to blow our previous out of the water. Just a few thread handling bugs to iron out for optimal results first…
pjmlp•4mo ago
andydotxyz•4mo ago
But the runtime of a Go app is, by default, faster than Java and my experiences have shown much, much better performance with the sort of multi-window full screen throughput we need for building a desktop.
pjmlp•4mo ago
Also this was mostly interpreted back then, without JIT compiler support.
Also to note,
> Regardless of the threat, Sun determined that the project was not a priority and decided not to put more resource to develop it to product quality. The project continued in an experimental mode, but with Sun's finances deteriorating, it became inactive in late 2006
Written from a Java userspace powered mobile phone, with 75% worldwide market share.
SkiFire13•4mo ago
sapiogram•4mo ago
You can do the same in any language with threads, and a library providing channels. Hell, you could probably do it better with a library, go's channels are unnecessarily error prone with nils, channel closing, and cleanup behavior.
tsimionescu•4mo ago
Not sure how relevant this is for UI operations, to be fair. The C#/JS style async/await model actually seems more amenable to controlling which works happens on the necessarily single GUI thread and which parts happen in background threads, and how to sync them later.
ikiris•4mo ago
andydotxyz•4mo ago
nickcw•4mo ago
ikiris•4mo ago
andydotxyz•4mo ago
pjmlp•4mo ago