search

tumblr / colossus

I/O and Microservice library for Scala
Apache License 2.0
1.14k stars 96 forks source link

Release 0.8.4 #518

Closed benblack86 closed 7 years ago

benblack86 commented 7 years ago

Currently stuck on milestone.

benblack86 commented 7 years ago

@DanSimon you ok with me releasing master as 0.8.4?

benblack86 commented 7 years ago

Doing now

DanSimon commented 7 years ago

Don't think we ever did any release candidates for 0.8.4, but given that the changes were only a few small bugfixes it's probably fine 👍

benblack86 commented 7 years ago

Just so I document this correctly, we should always do a RC first? When should we do a milestone?

DanSimon commented 7 years ago

Yeah I don't think we have it really solidified, but generally here's what I've gone with:

Milestones are meant for when a significant amount of work on a version has been done, but not all of it, and you want to do some more extensive testing of it. Personally I've used them to track performance changes and observe how impactful API changes are to real-life code. So like I'll just switch a service's version to the milestone and see what doesn't compile or what tests fail. Generally milestones should never be deployed in a production service. For a major release like 0.9.0, binary/API compatibility is expected to be broken between a milestone and the final release.

Release candidates are for when a version is code-complete and we're just looking for any lingering issues, so there are no more milestones (if any) once a RC is published. They are expected to be binary/API compatible with the final release and they can be tested in production services. Generally you keep pushing out RC's until you've gone some time without finding any new bugs, so the final release should be exactly the same as the last RC.

So it's generally up to your discretion whether a version needs any M/RC releases. 0.8.4 is pretty small so I think it's fine if we did neither.