it's even worse, because you don't get a group of faithful friends who bring you coffee every morning

I remember when I first started learning Node.js and looking at the issues for the Sails.js framework. I was reminded of something Dustin Hoffman’s character said in Hook: “Me me me me mine mine mine mine now now now now.”

I actually believe one of the worst things that can happen to an open source project not backed by some corporation is to be successful...

I like date versions because it is easiest to create new version. I don't have to think about anything and I don't have to know which version is previous one in order to create new one... here is is automatic versioning of commits on master: https://github.com/nenadalm/postgresql-log-viewer/blob/c55b8751e871c57362543976327e78abcbcd1496/.github/workflows/ci.yml#L45

I moved from commit count to release count since I found just bumping a number much easier and more predictable

The next version of #babashka-neil will help with that pattern with a new neil version patch command as well, similar to npm version

do version numbers ever work? i run into breaking changes in non-major version bumps for a lot of deps i use

date versions are nice to look at, and when i do lein search i can use dates to prioritise the rest of my day as i look at code and docs from the different deps i'm thinking of bringing in.

@U662GKS3F ah ok that's pretty cool! But what if you want to to support multiple major versions :thinking_face: what would you name the branches? Most libraries don't really have that problem but at my old job we supported multiple major versions with date branches and it was kinda ugly. The versioning at that job was SO BAD though, they mixed date versions and semver versions everywhere. It was a mess.

@U04V15CAJ I like the tag count! I haven't used neil yet but I'm going to start :3

@U0LAJQLQ1 Ah that's a good point about judging the freshness of the library based on date tags. I haven't thought about that!

I prefer not to keep multiple versions alive 🙂. Luckily I never had to maintain anything like that but I would try to have no breaking changes as much as possible and potentially introduce some new namespaces with duplicate code if necessary as described by Rich (https://www.youtube.com/watch?v=oyLBGkS5ICk&ab_channel=ClojureTV). I would be really annoyed if somebody forced me to maintain many versions of the same code in different branches :).

@U662GKS3F That's a great point. That job taught me that how painful and costly maintaining mutiple major version branches across many cooperative repos can be.. I'm gonna try my hardest to never be responsible for that kind of madness again 😝 I don't think I've seen this Rich talk yet.