I don’t think there’s any room to argue that announcing a 1.x with a change the developers say is a breaking change, which is what Immich have done, fits within the semver.org guidelines.

That wasn’t the argument.

Following semver is optional. If a project doesn’t explicitly state it is following semver, it shouldn’t be assumed that it is. With regard to Immich in particular, a cursory review of their documentation makes it clear that they are not following semver. Literally, go to https://immich.app/ and read the text at the very top of the page:

⚠️ The project is under very active development. Expect bugs and changes.

Go to the repo and you’ll see the README, which states at the very top:

• ⚠️ The project is under very activedevelopment.
• ⚠️ Expect bugs and breaking changes.

If you can read that, see that they’re on major version 1 with a minor version over 100, and you still think they’re using semver, then that’s on you.

The devs have stated they won’t be using semver until they consider Immich production ready, and that moving to a 1.x version from 0.x was a mistake made some time ago. If you want to think about it as though it is semver, consider the major version to still be 0. See https://github.com/immich-app/immich/discussions/5086#discussioncomment-7593227 for example.

As this project is clearly not following semver, the semver guidelines aren’t applicable and haven’t been violated.

I don’t think there’s any room to argue

Even if semver were applicable, in this case, I would still disagree. The text from semver.org states:

8. Major version X (X.y.z | X > 0) MUST be incremented if any backward incompatible changes are introduced to the public API.

It doesn’t state that any backward incompatible changes, period, require a major version increase, only changes to the public API. I would personally argue that the deployment configuration is part of the public API, but not all project owners agree with me. Even if they do agree, they might say that this was not a documented deployment configuration and thus not part of the public API, and that it therefore doesn’t necessitate an increase to the major version, but as they knew that people were using that configuration, anyway, they included a note about a potentially breaking change as a courtesy to those users.

Immich isn’t a library (the main use case for semver is dependencies that will be pulled into other projects) and as far as I know they don’t state that they use semver.

Certainly the latter.

I have pretty decent insurance through work, but if I’m picking up a prescription, it’s cheaper for me to say I don’t have insurance and use a free discount card (like GoodRx) than to use my insurance. We’re talking $150-$200 for one prescription (a one month supply) with insurance vs $30 without.

To be fair, I have an HDHP with an HSA so my insurance is only supposed to negotiate a discount until I hit the deductible, rather than paying for it. Full price is $200-$250, I think? (I get generics and each generic variant has a slightly different price.) So technically they’re providing a discount, just not a very good one.

Insurance also likes to require a “prior authorization,” which was always a fun surprise after making it through the pharmacy line. That normally takes a couple days to resolve, at minimum, and sometimes longer. If you’re not familiar with prior auths, it’s basically when the insurance company says “Hey doc, can you justify why you’re prescribing this and answer these eight questions?” and then they have someone without a medical degree review the answer and see if it’s good enough.

The only downside to paying out of pocket with a discount card is that the $30 doesn’t go toward my deductible. But since my deductible is multiple thousands of dollars, unless something else happens during the year, I won’t hit my deductible off the $150-$200 prescriptions + regular doctor visits alone. But that’s at most $360 out of pocket that wouldn’t have gone toward the deductible, assuming I had a health crisis in December, vs $1440-$2040 saved if I don’t.

X-rays are even worse, because you’re not told the price ahead of time.

Illegal vote suppression elected Trump, but even if it hadn’t, you should blame Democrats before blaming people who voted for third party candidates. Now, if you’re talking about people who “protest voted” by voting for Trump (in both the primaries and the election), then sure. Those people did, in fact, play an instrumental part in electing him.

Why blame Democrats? Well, beyond just kinda being Republican-lites:

• for opposing ranked choice voting (and alternatives)
• for not rallying around progressive candidates
• for not choosing Kamala via primary elections in 2024

Democrats are the bare minimum “harm reduction” party, and I don’t bare any ill will toward people who voted for them rather than a party that would actually try to effect change, but the opposite mindset - blaming third party voters for not voting for Democrats - is very shortsighted. And as third party voters have never had the power to enact RCV or STAR voting or otherwise improve the system, blaming them instead of the Democrats who have had that power is inane.

I’ve voted for a Democrat every single presidential election that I’ve been able to, but I honestly wish I hadn’t. I’d much rather there be more visibility for third parties, and for more people to feel empowered to vote for third party candidates.

Glaring doesn’t imply a negative meaning. In this case it’s used to mean “obvious”.

Unless you’re suggesting that “glaring” means “obviously staring” (it doesn’t - that would be “glaringly staring”) this doesn’t make any sense.

“[He’s] glaring at [direct object]” is an example of a sentence that uses the present participle form of the verb “glare,” which explicitly communicates anger or fierceness.

If you’re not convinced, read on.

—————

The verb form that takes an object is:

Glare (verb with object): to express with a glare. They glared their anger at each other

The noun form the above definition references is:

Glare (noun): a fiercely or angrily piercing stare.

“Glaring” can be an adjective and one of those definitions does mean “obvious” or “conspicuous,” but the use of that form of the word doesn’t make sense in her sentence. Think about a comparable sentence like “The undercover operative is conspicuous at the bar,” where the bar is the location. (Even then, most people wouldn’t use “glaring” in that sentence, as “conspicuous” or “obvious” are much less ambiguous; the operative could be staring piercingly or angrily at the bar rather than being glaring while being at the bar.) Another example that makes a bit more sense is “The effect of the invasive plants is glaring at the park.”

But for that interpretation to be valid here, you’d have to:

• believe that the dude is trying to hide/blend in, or otherwise explain how he - not what he’s doing, but the dude himself - is conspicuous
• believe that the woman’s referring to her own ass as a location
• assume that she isn’t commenting on how the guy is looking at her ass, even though the joke depends on giving him something different to look at

That’s a bit of a stretch.

This is what I would try first. It looks like 1337 is the exposed port, per https://github.com/nightscout/cgm-remote-monitor/blob/master/Dockerfile

x-logging:
  &default-logging
  options:
    max-size: '10m'
    max-file: '5'
  driver: json-file

services:
  mongo:
    image: mongo:4.4
    volumes:
      - ${NS_MONGO_DATA_DIR:-./mongo-data}:/data/db:cached
    logging: *default-logging

  nightscout:
    image: nightscout/cgm-remote-monitor:latest
    container_name: nightscout
    restart: always
    depends_on:
      - mongo
    logging: *default-logging
    ports:
      - 1337:1337
    environment:
      ### Variables for the container
      NODE_ENV: production
      TZ: [removed]

      ### Overridden variables for Docker Compose setup
      # The `nightscout` service can use HTTP, because we use `nginx` to serve the HTTPS
      # and manage TLS certificates
      INSECURE_USE_HTTP: 'true'

      # For all other settings, please refer to the Environment section of the README
      ### Required variables
      # MONGO_CONNECTION - The connection string for your Mongo database.
      # Something like mongodb://sally:sallypass@ds099999.mongolab.com:99999/nightscout
      # The default connects to the `mongo` included in this docker-compose file.
      # If you change it, you probably also want to comment out the entire `mongo` service block
      # and `depends_on` block above.
      MONGO_CONNECTION: mongodb://mongo:27017/nightscout

      # API_SECRET - A secret passphrase that must be at least 12 characters long.
      API_SECRET: [removed]

      ### Features
      # ENABLE - Used to enable optional features, expects a space delimited list, such as: careportal rawbg iob
      # See https://github.com/nightscout/cgm-remote-monitor#plugins for details
      ENABLE: careportal rawbg iob

      # AUTH_DEFAULT_ROLES (readable) - possible values readable, denied, or any valid role name.
      # When readable, anyone can view Nightscout without a token. Setting it to denied will require
      # a token from every visit, using status-only will enable api-secret based login.
      AUTH_DEFAULT_ROLES: denied

      # For all other settings, please refer to the Environment section of the README
      # https://github.com/nightscout/cgm-remote-monitor#environment

To run it with Nginx instead of Traefik, you need to figure out what port Nightscout’s web server runs on, then expose that port, e.g.,

services:
  nightscout:
    ports:
      - 3000:3000

You can remove the labels as those are used by Traefik, as well as the Traefik service itself.

Then just point Nginx to that port (e.g., 3000) on your local machine.

—-

Traefik has to know the port, too, but it will auto detect the port that a local Docker service is running on. It looks like your config is relying on that feature as I don’t see the label that explicitly specifies the port.

Ars points out that these findings contradict those of other experiments and then goes on to postulate as to why. I clicked on the link to the other experiment:

when data is combined across three experiments and 4,867 developers, our analysis reveals a 26.08% increase (SE: 10.3%) in completed tasks among developers using the AI tool

By comparison, this experiment considered 16 developers. That’s 0.3% as many as the experiments its findings contradict. Fortunately, the authors don’t claim their findings are broadly applicable. They even have a table that reads:

We do not provide evidence that | Clarification —- | —- AI systems do not currently speed up many or most software developers | We do not claim that our developers or repositories represent a majority or plurality of software development work AI systems do not speed up individuals or groups in domains other than software de- velopment | We only study software development AI systems in the near future will not speed up developers in our exact setting | Progress is difficult to predict, and there has been substantial AI progress over the past five years [2] There are not ways of using existing AI systems more effectively to achieve positive speedup in our exact setting | Cursor does not sample many tokens from LLMs, it may not use optimal prompting/scaffolding, and domain/repository-specific training/finetuning/few-shot learning could yield positive speedup

That said, the study has been an interesting read so far. I highly recommend reading it directly rather than just the news posts about it. Check out their own blog post: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

I personally find the psychological effect - the devs thought they were 20% faster even afterward - to be pretty interesting, as it suggests that even if more time overall is spent, use of AI could reduce cognitive load and potentially side effects like burnout.

I’d like to see much larger scale studies set up like this, as well as studies of other real world situations. For example, how does this affect the amount of time this takes 10,000 different developers to onboard onto an unfamiliar repository?