I certainly don't meant to rehash something that has been discussed ad-nauseam. Nor am I advocating we change how often we release. I think the key distinction is picking a version number that indicates breaking change, compatible changes/new features, vs patches. Semantic versioning provides a clean way to do specify this. In npm and ruby land, this has largely fixed dependency hell, and has led to more reliable code re-use.
Just a thought. http://semver.org On Wed, Oct 3, 2012 at 5:37 PM, Filip Maj <f...@adobe.com> wrote: > This discussion again :) > > http://apache.markmail.org/thread/l2et3r5v35efprgd > > > With a point release coming out every month or so that limits us to being > able to "break" things every 10 months or so. With changing SDKs (see iOS > 4.2, 5, and 6) sometimes we need to break things, like, asap. > > Other times we break things because we are assholes (from our users' point > of view, at least :P ) > > On 10/3/12 2:21 PM, "Mike Reinstein" <reinstein.m...@gmail.com> wrote: > > >I'm wondering if anyone else has given thought towards adopting semantic > >versioning for our releases. In terms of making plugin development and > >version adoption less painful, this might be a good move. Thoughts? > > > >-Mike > >
