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
