Well, considerting annoying push for "let's resolve the issue on discord" it's very annoying. With things like github issues you can search for a problem and find a solution. Even ancient mailing lists most of the time have archives. Not so much with all those fancy "realtime" :/
I agree with the sentiment but GitHub issues is not a good replacement. First, it’s also owned by a corporation and is available on the open web today because they let us (is it even scrape/api available today? Can people build tooling on top?). Anyway, this “openness” can easily be changed once the “value extraction knob” is turned.
Secondly, GitHub is a developer platform, not a user/enjoyer platform. Issue reports are high-barrier even for devs. People get upset if you’re asking a random question, don’t check for duplicates, etc. Some people even get upset about issues without a PR.
Again, I’m all for good open alternatives but when HN is like “you just configure Gentoo and type 30 commands” we don’t stand a chance to actually win users over, gotta accept reality before we can improve it…
I use this for my Lemmy instance & lemmy-ansible and it's been great! No longer having to support upgrade scripts and write a complete upgrade process[1] for people to follow has made my life a lot easier! Amazing product
I heard about that project but it still somewhat convoluted. Imagine being able to simply use "postgres:latest" or better yet "postgres:15" and switch to "postgres:16" and it would just update (like any other minor version does, or any other db, like mysql, does)
Btw, what do you find convoluted about our project (pgautoupgrade)?
It started out as super simple like you mention above... but it also started out using Alpine images so didn't work so well for people coming from Debian based ones. We've added support for Debian based ones now too, but that's introduced more complexity to the README (as has other options). o_O
pg_upgrade is a bit manual at the moment. If the database could just be pointed to a data directory and update it automatically on startup, that would be great.
Being able to simply switch from "postgres:15" to "postgres:16" in docker for example (I'm aware about pg_autoupdate but it's external and I'm a bit iffy about using it)
What's more, even outside of docker running `pg_upgrade` requires both version to be present (or having older binary handy). Honestly, having the previous version logic to load and process the database seems like it would be little hassle but would improve upgrading significantly...
It would be a major hassle to do so since it would mean keeping around major parts of the code for all old versions of PostgreSQL. Possible to do? Yes. A hassle for the dev team? Yes, a huge one. Worth it? Doubtful.
Patches welcome since you obviously know more than me about the code base. And I obviously meant only major versions when I said all versions. PostgreSQL releases one new major version per year so that adds up quickly.
> I don't expect PostgreSQL changing that significantly between major version the upgrade would be such a huge hassle…
PostgreSQL would need code which transforms between the old AST to the new AST for example to support views and check constraints so PostgreSQL would need to keep around a version of the AST for every major version of PostgreSQL plus the code to deparse it. It would also need to keep around the code to read every version of the catalog tables (it partially does this in pg_dump, but only partially since parts of pg_dump is implemented using server side functions).
There are also likely a bunch more complications caused by the pluggable nature of PostgreSQL: e.g. custom plan nodes which might make the whole project a non-starter.
So this would at least mean basically a total rewrite of pg_dump plus maintaining 5 to 10 versions of the AST. But likely much more work since I have likely forgot a bunch of stuff which needs to change. A huge project which increases the maintenance burden for a relatively small gain.
> TBH PostgreSQL seem to be the only tool/software that has such a bonkers upgrade path between major versions…
This is caused mostly by PostgreSQL being heavily extensible unlike its competitors.
> A huge project which increases the maintenance burden for a relatively small gain.
No, it would be for a huge gain for the people who run PostgreSQL. Every long running PostgreSQL installation use has to go through the process and/or potential downtime figuring out a (potentially forced) upgrade every few years.
Instead of that, PG being able to transparently (or at least automatically) upgrade major versions as needed would remove that absolutely huge pain point.
Other databases have recognised this as being a major problem, then put the time and effort into to solving it. The PostgreSQL project should too. :)
Argh... Firefox and gitlab (I hate web-"apps") is dumb. When you click on the file it shows "download" (because gitlab can't be bothered with preview) and when clicking on it firefox open new page as "preview" without anything on there and while trying to save it saves as "html" file and not the actual jxl file... obviously, because gitlab is shaite "app" it's not possible to click on any download button and select "save target as"
EDIT: Managed to save it and Finder preview (space) worked just fine :)
Each time I have to touch it, it results in problems... Oh, you updated JDK? Gradle won't work. There is new Gradle? Tough luck it will break your build..
And with Maven it can update and the build keeps working just fine.
To that end I mostly ignore prompt "update gradle!" in Android Studio to avoid any issues...
Maven (and pretty much every other build tool with the exception of bazel) is not capable enough for such a complex build as is required for android, though. E.g. maven can often “lose” that something requires a rebuild, and only clean build will produce the correct artifacts. Gradle can always keeps track of tasks correctly.
Maven (and pretty much every other build tool with the exception of bazel) is not capable enough for such a complex build as is required for android, though.
Maven is virtually infinite extensibility via plugins. The difference is that gradle is easier to "hack" and put the build logic in your configuration...
> E.g. maven can often “lose” that something requires a rebuild, and only clean build will produce the correct artifacts.
This is not build shortcoming but rather detection what requires rebuild and what not but in the worst case scenario it rebuilds everything…
> Gradle can always keeps track of tasks correctly.
LOL, from my experience that is not true.
Also, if you have multiple projects using different gradle version this results in multiple daemons running in the background. Besides gradle builds as as slow as maven...
> Maven is virtually infinite extensibility via plugins
Losing the only task of a build tool, caching and parallelization.
No, the problem is that maven doesn’t rebuild everything. It is actually quite common in code bases that I had to run clean build instead of build to actually recompile everything that changed. I guess maven just doesn’t have an accurate build graph?
> LOL, from my experience that is not true
In what way is it not true?
Also, gradle is demonstrably faster, especially on projects that can be parallelized. Obviously a hello world will be dominated by javac and build tool startup speed so it’s not relevant.
And multiple daemons — you can disable them, and they will go away if unused.
> Losing the only task of a build tool, caching and parallelization.
You are aware that Maven does offer paralle build, right?
> I guess maven just doesn’t have an accurate build graph?
You guess wrong? then
>> LOL, from my experience that is not true
> In what way is it not true?
Consistency of gradle build. You yourself stated just a paragraph above that sometimes you have to run "clean" xD
> Also, gradle is demonstrably faster, especially on projects that can be parallelized. Obviously a hello world will be dominated by javac and build tool startup speed so it’s not relevant.
Again, learn the tool. Maven does offer parallel builds and is comparably fast…
> And multiple daemons — you can disable them, and they will go away if unused.
"but you are turning off the only feature of a build!!!"
Also - I had a setup open with gradle/kotlin-multiplatform project (shell with "gradlew" and Android Studio) and magically it fails to build with "Unresolved reference: kotlinx" even though I haven't done anything to the project and no ammount of running "gradlew clean" solves it... what a lovely tool....
I tried and
* commons took more than 2,5 minutes to build (they show 70s?)
* tried their tests (medium project, https://github.com/gradle/performance-comparisons/tree/maste...) and maven compiled it in 4s and usual "clean install" took 14s but they don't enable paralel test run); then I tried running "gradle build" and... got an error:
* What went wrong:
A problem occurred evaluating root project 'single-medium-project'.
> Could not find method compile() for arguments [commons-lang:commons-lang:2.5] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler.
```
It's so nice that even gradle team themselves can keep up with their crap xD but of course it's probably due to convoluted setup... again - with maven you just clone and build and be done with it, with gradle you have to "stand on your head" to figure how to make any progress... I updated the build.gradle (according to https://docs.gradle.org/current/userguide/declaring_dependen...) and `gradle build` finished in 19s...
So your beloved gradle is 25% slower and can't even be compatible with itself...
I took a look at "large-multimodule" to have something more challenging but: they setup each project individually and for some convoluted reason configure maven compiler with `<source>1.5</source>` (and JDK21 complains) and same goes for gradle modules with broken `dependencies`. I adjusted it but then it turned out that the sources can't even compile (due to wrong arguments in tests) ffs...
Maven is more as capable for anyone that doesn't suffer from XML allergy, and doesn't require a background daemon to actually make it run at reasonable speed.
Correctness is the number 1 priority, and maven is simply not always doing what it should, unless you do a clean build.
I am absolutely not bothered by XML and alia (btw, there are maven frontends in json/yaml, etc for those who are), and throwing out valid criticism over some straw man is not really productive.
I’m still learning about the tools and their pros and cons. Can you provide an example of a case where Maven would not do what it should? Are there particular bug reports or bug reproduction repos that you’ve seen?
Context: I worked on a Spring app many years ago and am picking Java back up.
But I have run into issues with multi-module projects and the like, and it can be very frustrating to realize that you are trying out some corrupt version. Nonetheless, maven is also a cool and stable tool, but you are better off adding a clean step from time to time.
And if you are in a regulatory environment (or elsewhere where data exfiltration paranoia is part of your daily work life), you can install your own instance of the service (sans premium features) and not send your text anywhere outside infrastructure you control.
reply