* +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? * I don't have experience with CLIRR et al. What's the overhead involved w/ setting this up for all our APIs?
--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 >
