search

humanmade / Cavalcade-Runner

Daemon for Cavalcade, a scalable WordPress jobs system.
https://engineering.hmn.md/projects/cavalcade/
53 stars 26 forks source link

Tag a release so people don't have to use dev-master #60

Closed Jalle19 closed 3 years ago

badrange commented 5 years ago

That would be helpful!

btorellALTA commented 4 years ago

Yes please! If the idea behind Cavalcade is that people can use this in a horizontally scalable system like Kubernetes, then I don't want my Dockerfile to have to install this from master lest a random build accidentally updates things unexpectedly. For the time being I will have to explicitly check out commit hashes instead.

rmccue commented 4 years ago

FWIW, we wouldn't recommend referencing master. You should reference the commit hashes directly instead (which are a type of version).

I'll look into tagging :) FWIW though, you probably don't want to load this in via Composer in most cases, but rather as part of the system's infrastructure instead.

btorellALTA commented 4 years ago

Sure, but checking out a hash is an extra step. I can git clone --branch to get an explicit tag or branch all at once. If I want a particular hash, I have to git clone and then git checkout, which is awkward.

Having versioned releases also prevents potential problems where master might have a series of non-functional commits. If the assumption is that you can just check out a hash, the promise has to also be that any hash should be completely functional. In my experience, most repositories end up having a few hashes that are followed by a "fixup" commit, or maybe a revert. Tagged releases are a way to indicate known-good code states.

Finally, versioned releases can also be a way to ensure that Cavalcade-runner is compatible with a particular version of the Cavalcade plugin itself. If a change is made to Cavalcade such that a change needs to be made to the runner, semantic versioning is a good way to indicate API-level changes to help people understand what they need to ensure things are working together properly. It's easier to say "This version of Cavalcade requires version X.Y.Z of Cavalcade-runner" or vice versa.

rmccue commented 4 years ago

In my experience, most repositories end up having a few hashes that are followed by a "fixup" commit, or maybe a revert.

This isn't the way we operate; all changes go through pull requests, and we run the latest code in production (per our support promise). This repository moves very slowly, because Cavalcade is essentially complete.

If we fix something up in a follow-up PR, that's not fundamentally different to 1.0.0 vs 1.0.1 :) Ultimately, it's your responsibility to vet any software you're running, and you shouldn't be checking out a branch; always pin your versions.

With that said, don't get me wrong, versioning makes a lot of sense, but we don't need it, which is why it hasn't been done yet.

archon810 commented 4 years ago

Please consider adding tags/releases so that we at least have an understanding of when you consider your code in master stable, attach release notes, etc.

roborourke commented 3 years ago

We've now tagged 1.0.0 as the latest stable version and 1.0.1 which has the fix from #64

We'll follow standard Semver from here on out as PRs are merged but updates will be very rare still.