On Tue, May 11, 2010 at 1:55 PM, Paul Lindner <[email protected]> wrote:
> 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 > Nope, I did say it was a dumb question. :) I'm clearly @head. Plan sounds good to me, assuming the overhead of maintenance/conformance isn't too high. --j > 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 > > > > > >
