Here's some sample clirr output.. (that was easy!) Clirr Results
The following document contains the results of Clirr<http://clirr.sourceforge.net/> . - Current Version: 1.1-BETA6-SNAPSHOT - Comparison Version: 1.0.1 SummarySeverityNumber[image: Error] Error29[image: Warning] Warning0*(The results have been filtered to omit less severe results)* DetailsSeverityMessageClassMethod / Field[image: Error]Field AUTH_UNAUTHENTICATED has been removed, but it was previously a constant org.apache.shindig.auth.AnonymousAuthenticationHandler<./xref/org/apache/shindig/auth/AnonymousAuthenticationHandler.html> AUTH_UNAUTHENTICATED[image: Error]Method 'public java.lang.String toSerialForm()' has been removed org.apache.shindig.auth.AnonymousSecurityToken<./xref/org/apache/shindig/auth/AnonymousSecurityToken.html>public java.lang.String toSerialForm()[image: Error]Method 'public java.lang.String getWWWAuthenticateHeader(java.lang.String)' has been added to an interface org.apache.shindig.auth.AuthenticationHandler<./xref/org/apache/shindig/auth/AuthenticationHandler.html>public java.lang.String getWWWAuthenticateHeader(java.lang.String)[image: Error]In method 'public BasicSecurityToken(java.lang.String, int)' the number of arguments has changedorg.apache.shindig.auth.BasicSecurityToken<./xref/org/apache/shindig/auth/BasicSecurityToken.html>public BasicSecurityToken(java.lang.String, int)[image: Error]In method 'public BasicSecurityToken(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String)' the number of arguments has changedorg.apache.shindig.auth.BasicSecurityToken<./xref/org/apache/shindig/auth/BasicSecurityToken.html>public BasicSecurityToken(java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String, java.lang.String)[image: Error]Method 'public java.lang.String toSerialForm()' has been removed org.apache.shindig.auth.BasicSecurityToken<./xref/org/apache/shindig/auth/BasicSecurityToken.html>public java.lang.String toSerialForm()[image: Error]Field crypters is now final org.apache.shindig.auth.BlobCrypterSecurityTokenDecoder<./xref/org/apache/shindig/auth/BlobCrypterSecurityTokenDecoder.html> crypters[image: Error]Field domains is now final org.apache.shindig.auth.BlobCrypterSecurityTokenDecoder<./xref/org/apache/shindig/auth/BlobCrypterSecurityTokenDecoder.html> domains[image: Error]Parameter 1 of 'public BlobCrypterSecurityTokenDecoder(org.apache.shindig.common.ContainerConfig)' has changed its type to org.apache.shindig.config.ContainerConfig org.apache.shindig.auth.BlobCrypterSecurityTokenDecoder<./xref/org/apache/shindig/auth/BlobCrypterSecurityTokenDecoder.html>public BlobCrypterSecurityTokenDecoder(org.apache.shindig.common.ContainerConfig)[image: Error]Parameter 1 of 'public DefaultSecurityTokenDecoder(org.apache.shindig.common.ContainerConfig)' has changed its type to org.apache.shindig.config.ContainerConfig org.apache.shindig.auth.DefaultSecurityTokenDecoder<./xref/org/apache/shindig/auth/DefaultSecurityTokenDecoder.html>public DefaultSecurityTokenDecoder(org.apache.shindig.common.ContainerConfig)[image: Error]Method 'public java.lang.String getActiveUrl()' has been added to an interfaceorg.apache.shindig.auth.SecurityToken<./xref/org/apache/shindig/auth/SecurityToken.html>public java.lang.String getActiveUrl()[image: Error]Method 'public java.lang.String getAuthenticationMode()' has been added to an interface org.apache.shindig.auth.SecurityToken<./xref/org/apache/shindig/auth/SecurityToken.html>public java.lang.String getAuthenticationMode()[image: Error]Method 'public java.lang.String getContainer()' has been added to an interface org.apache.shindig.auth.SecurityToken<./xref/org/apache/shindig/auth/SecurityToken.html>public java.lang.String getContainer()[image: Error]Method 'public java.lang.Long getExpiresAt()' has been added to an interface org.apache.shindig.auth.SecurityToken<./xref/org/apache/shindig/auth/SecurityToken.html>public java.lang.Long getExpiresAt()[image: Error]Method 'public boolean isExpired()' has been added to an interface org.apache.shindig.auth.SecurityToken<./xref/org/apache/shindig/auth/SecurityToken.html> On Tue, May 11, 2010 at 1:57 PM, John Hjelmstad <[email protected]> wrote: > 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 > > > > > > > > > >
