I recently realized: fuck it, just have the build date as the version: 2026.02.28.14 with the last number being the hour. I can immediately tell when something is on latest or not. You can get a little cheeky with the short year '26' but that's it. No reason to have some arbitrary numbers represent some strange philosophy behind them.

[–] gandalf_der_12te@discuss.tchncs.de 2 points 1 hour ago

I use 2026-03-01-05 too but the -05 does not represent the hour but the number of version i release today. like if i make five commits today, they will be -01, -02, -03, ...

[–] psud@aussie.zone 1 points 19 hours ago

I used to work on a product with version numbers year.release - 2005.9 then 2005.10, though we only had about six releases a year

[–] the_wonderfool@piefed.social 30 points 1 day ago

Tried it in the past but ultimately abandoned it, as then release numbers lost all added meaning. I can remember what happened in release 2.0.0 or (kinda) 3.5.0, but what the hell was release 2025.02.15? Why did it break this random function?

[–] ilinamorato@lemmy.world 21 points 1 day ago (1 children)

Can you immediately tell? Do you memorize the last day you released? Do you release daily? There's definitely some benefit to making the version equal to the date, but you lose all the other benefits of semver (categorizing the scope of the release being the big one). That's not a strange philosophy, it's just being a good api provider.

[–] PieMePlenty@lemmy.world 9 points 1 day ago

You're right. I'm looking at it through a very limited scope: nightly releases. I've been working with "latest" so long, I forgot actual versions exist.

[–] grrgyle@slrpnk.net 2 points 1 day ago

I like using the short hash from the latest git commit used to build, to avoid confusion among multiple devs on parallel streams

[–] qarbone@lemmy.world -3 points 1 day ago (2 children)

The philosophy is pretty straight-forward. I don't know why the world is pretending it's difficult.

[–] ilinamorato@lemmy.world 1 points 2 hours ago* (last edited 2 hours ago)

Chesterton's Fence, but for workflows you don't understand.

[–] AnarchistArtificer@slrpnk.net 3 points 1 day ago (1 children)

It's usually safe to assume that If there are people who seem to find a thing difficult despite you finding it easy, it's probably difficult for them. For some reason or other, they have needs or struggles that you don't have. You don't need to understand why they struggle, just accept that they do.

[–] qarbone@lemmy.world 3 points 1 day ago (1 children)

I fundamentally cannot agree with that take. How do you fix something if you don't know why the current thing doesn't work?

Is the interface obtuse?

Are the controls too manually complex to operate?

Is the tutorial instruction flat-out wrong?

Are they talking out off their ass about something they heard on hearsay?

Were they taught secondhand, and poorly, by someone else on how to operate Thing?

Please don't try to imprecisely apply soft inclusivity to technical problems. If someone only says the stairs are difficult for them, don't just change them into a slide because you accepted there needs to be change. This isn't about accomodating someone's lifestyle choices, this is (positing) dropping/adopting a standard based on vague dissent.

[–] pupbiru@aussie.zone 1 points 1 hour ago* (last edited 1 hour ago)

i took the phrase

You don't need to understand why they struggle, just accept that they do.

to mean that you shouldn’t assume someone is lying. they just might have different circumstance or needs. that doesn’t invalidate their experience, just that you’re solving different problems (which may not have been well communicated, and also may not even be technical problems).

if you’re trying to solve their problems, then sure that’s a discussing… but 99% of tech conversations on the internet like this are people berating others for “not understanding” the “simple” way it’s done because it works fine for them