You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Paul Lindner <li...@inuus.com> on 2010/05/11 22:42:52 UTC
nailing down the shindig roadmap.
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
Re: nailing down the shindig roadmap.
Posted by Paul Lindner <pl...@linkedin.com>.
Okay, I updated JIRA with the dates below..
May 18 - 2.0.0-RC1
May 25 - 2.0.0
Time for a commit-fest!
Going forward we'll evaluate the state of the branches at the beginning of
each month.
Thanks!
On Wed, May 12, 2010 at 2:23 AM, Tim Wintle <ti...@teamrubber.com>wrote:
> On Tue, 2010-05-11 at 13:42 -0700, Paul Lindner 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
>
> +1 on the numbering and making the next release 2.0.0
>
> > * 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.
>
> +1
>
> 1.0.1 is very noticeably different from trunk, and for those of us who
> get little time to follow trunk development it's important to have a
> stable release to pull without worrying about breakages too much.
>
>
Re: nailing down the shindig roadmap.
Posted by Tim Wintle <ti...@teamrubber.com>.
On Tue, 2010-05-11 at 13:42 -0700, Paul Lindner 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
+1 on the numbering and making the next release 2.0.0
> * 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.
+1
1.0.1 is very noticeably different from trunk, and for those of us who
get little time to follow trunk development it's important to have a
stable release to pull without worrying about breakages too much.
Re: nailing down the shindig roadmap.
Posted by Paul Lindner <pl...@linkedin.com>.
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 <fa...@google.com> wrote:
> On Tue, May 11, 2010 at 1:55 PM, Paul Lindner <pl...@linkedin.com>
> wrote:
>
> > On Tue, May 11, 2010 at 1:47 PM, John Hjelmstad <fa...@google.com>
> 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 <li...@inuus.com>
> 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
> > > >
> > >
> >
>
Re: nailing down the shindig roadmap.
Posted by John Hjelmstad <fa...@google.com>.
On Tue, May 11, 2010 at 1:55 PM, Paul Lindner <pl...@linkedin.com> wrote:
> On Tue, May 11, 2010 at 1:47 PM, John Hjelmstad <fa...@google.com> 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 <li...@inuus.com> 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
> > >
> >
>
Re: nailing down the shindig roadmap.
Posted by Paul Lindner <pl...@linkedin.com>.
On Tue, May 11, 2010 at 1:47 PM, John Hjelmstad <fa...@google.com> 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 <li...@inuus.com> 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
> >
>
Re: nailing down the shindig roadmap.
Posted by John Hjelmstad <fa...@google.com>.
* +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 <li...@inuus.com> 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
>