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. (That said if anyone here wants a ticket to http://pgday.phonegap.com just hit me up off list so we can get you there.)
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. On Tue, Jul 10, 2012 at 11:41 AM, Patrick Mueller <[email protected]> wrote: > On Tue, Jul 10, 2012 at 2:19 PM, Filip Maj <[email protected]> wrote: > >> Timing is an interesting question that keeps coming back up, tying back to >> our deprecation policy and our versioning approach. If we are going with >> our current deprecation policy (time-based, 6 months or so), then this is >> at odds with the combination of a) our release cadence and b) users' >> expectation of semantic version, I.e. Breaking changes landing in major >> revisions. If we release a point revision every month, this means we have >> (worst case) 10 (or 12, depends on how many point revisions we have in a >> major release) months between when we can land breaking changes. 6 month >> dep policy vs. anywhere from 1 to 10 months of next major release = >> something's gotta give. > > > As the person who brought up the "split stream" suggestion months ago, > which IIRC was liked by no one but me :-( , have we considered even/odd > versioning [1], like what node does? (tip: it's the same thing I suggested > before, just a different name :-) ) > > We need both: > > - the freedom to break APIs (odd versions) > - a stable platform for our customers (even versions) > > Perhaps we can noodle on that, and other approaches, before next week, when > some of us are able to wrastle over it in meat-space. > > [1] > http://en.wikipedia.org/wiki/Software_versioning#Odd-numbered_versions_for_development_releases > > -- > Patrick Mueller > http://muellerware.org
