On Tue, Jul 10, 2012 at 3:17 PM, Brian LeRoux <[email protected]> wrote:
> Agree, this will be a whole lot easier to figure out in a F2F over
> beers but obviously will bring everything back to the list to make any
> final decisions.
Of course.
> One thing I'd like to add: cadence has nothing to do w/ deprecation
> policy. Shipping on a regular heartbeat is a completely different
> concern from the actual artifacts being shipped.
>
Here's an example / generalization of cadence that you might see with an
even/odd release stream:
fixes/enhancements to stable that don't break API
- version change: x.(even).z -> x.(even).(z+1) eg, 2.0.0 -> 2.0.1
- occur as needed, hopefully/presumably not often
monthly cadence for developers in dev stream
- version change: x.(odd).z -> x.(odd).(z+1) eg, 2.1.3 -> 2.1.4
- every 4 weeks, or whatever
major release
- version change: x.(odd).z -> x.(odd+1).0 eg, 2.1.42 -> 2.2.0
- every so many months?
Presumably the version numbers have matching branches/tags in git, as
appropriate, for both even and odd releases. Would be interesting to see
exactly how node does that (perusing their branches/tags right now ...)
--
Patrick Mueller
http://muellerware.org