Schedule for next minor release? #964
-
|
Hi, I am interested in fixing this small TODO: https://github.com/jwtk/jjwt/blob/master/extensions/jackson/src/main/java/io/jsonwebtoken/jackson/io/JacksonDeserializer.java#L118. It looks like the change should go in the next minor release so I'm wondering if that has been scheduled already and/or what the cadence for minor releases is? Thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
Hi @petroav ! We don't have a timed or scheduled release cadence - we only rely on semantic versioning to determine release numbers. When we increment version numbers is really just a matter of if it feels right to do so. It's always easy to cut a patch release any time, without delay, since patch releases imply forward and backward API compatibility in the Maj.min.XXX versions (i.e. no public API changes). Cutting the next Maj.min.0 release however takes some thought and planning - each new public API feature needs to be documented well, and there usually needs to be at least two or three issues to warrant the work necessary. There are currently 3 issues slated for the 0.13.0 milestone, so once they're done, and any other ancillary changes along the way, we'd probably release that version since it feels like enough substance to warrant the minor version change. It's always a bit of a balance as to what makes sense based on our workload and how many people are asking for a release. I hope that helps! |
Beta Was this translation helpful? Give feedback.
-
|
@lhazlewood thanks a lot for the details! I actually see now that there's an issue to make the constructor in question public (#914). I'll watch that task as a proxy for when the |
Beta Was this translation helpful? Give feedback.
Hi @petroav !
We don't have a timed or scheduled release cadence - we only rely on semantic versioning to determine release numbers.
When we increment version numbers is really just a matter of if it feels right to do so. It's always easy to cut a patch release any time, without delay, since patch releases imply forward and backward API compatibility in the Maj.min.XXX versions (i.e. no public API changes). Cutting the next Maj.min.0 release however takes some thought and planning - each new public API feature needs to be documented well, and there usually needs to be at least two or three issues to warrant the work necessary.
There are currently 3 issues slated for the 0.13.0 milestone, …