On Tue, May 11, 2010 at 1:47 PM, John Hjelmstad <[email protected]> wrote:
> * +1 on the standard x.y.z versioning scheme, with definitions as provided. > * Dumb question, why's the next one 2.0.0 in this case? What's the big > external API break? > Have you looked at the diff between 1.0.1 lately? External dependencies are difference, many of the data models have changed, and more.. I've been collecting a few of the recent changes in UPGRADING, but that's just the tip of the iceberg. > * I don't have experience with CLIRR et al. What's the overhead involved w/ > setting this up for all our APIs? > There's a maven plugin for it. I'm trying it out... > --j > > On Tue, May 11, 2010 at 1:42 PM, Paul Lindner <[email protected]> wrote: > > > We've done a pretty poor job of spinning off releases and providing > > guidance > > to consumers of shindig. I'd like to change that. Here's my take on > > this... > > > > * Versioning > > > > We just released 1.0.1, which is the first (and maybe the last 1.0 > > version). > > I'd like to go with three version identifiers: > > > > Breaking External API Changes / Breaking Internal API Changes / Bug > fixes. > > > > Based on this we'd next release version 2.0.0, which would have API > > stability through the 2.0.x series of releases. > > > > A version 2.1.0 could adjust internal implementations / APIs, but could > not > > break Guice Modules or the APIs of Data Models used by third parties. We > > can help this effort by making Abstract Base classes for implementations > > that will allow us to introduce new methods without causing consumer code > > to > > break. > > > > * Proposed Roadmap > > > > We should admit that we won't be able to deliver all of the opensocial > 0.9 > > functionality and release a 2.0 release. Enough of us are running off of > > trunk and the code is stable. We should ship and document our > conformance > > with the spec. My proposal is: > > > > 2.0.x stable 0.9 > > 2.1.x 1.0 non-breaking features > > 3.x.x More radical changes > > > > To get us to 2.0.x we should try and get as many API breakage changes out > > of > > the way, clean up classes in 'old' packages, and do it with a deadline, > say > > 1 or 2 weeks from today. At the end of that cycle we'd roll out a > > 2.0.0-RC1, allow it to bake for two more weeks and if no serious problems > > crop up release it as 2.0.0 final. > > > > At the same time we can then move trunk to a 3.x cycle. 2.1.0 changes > can > > either be backported or developed on feature branches of 2.0.x and so on. > > > > Every month we should evaluate the branch status, either release a point > > release, or decide as a group to move onto the next internal > > breaking/external breaking change. > > > > We'll have to be more careful about API compatibility. CLIRR or some > other > > tool should be used to verify that APIs don't break within a release > cycle. > > > > * Proposed Calendar > > > > commit everything you can :) > > May 17 - 2.0.0 feature freeze 2.0.0-RC1 build, create branches/2.0.x > > branches/2.1.x > > May 25 - 2.0.0 release > > Jun 1 - 2.0.1 release (if needed) > > Jul 1 - 2.0.2 and/or 2.1.0 and/or 3.0.0 > > Month++ - repeat > > >
