On Fri, Dec 19, 2008 at 7:11 PM, Adam Winer <[email protected]> wrote:
> +1, though as you say we might need to play around with what's meant by
> "features".
> I totally agree it does not make sense to force PHP and Java to have the
> same release cycle. Would a major rearchitecting of the Java code
> necessarily be matched by the PHP code, or vice versa? If not, you'd get
> into an odd state of releasing Shindig PHP 2.0 because of a major Java
> rewrite. Or we could be in a state where we can't release a critical
> bugfix
> on PHP, because Java isn't in a release-ready state. Etc...
>
In the past, say 11 months or so, the two versions have been pretty similar
in it's development cycles.
Both versions are spec driven, which goes at a high enough pace that that is
*probably* what our releases will be timed around. Both use the same
javascript code, which means that if one of the 2 versions were to require a
change in it that affects anything other then pure client side, it would
have to be updated in both versions not to cause breakage on either side.
Also the security issues, general technologies & configuration of both
versions is so similar (save some language specific details), that having to
re-invent the wheel, and splitting up our know-how over different groups
seems a waste of resources (and to be honest I count on the shindig
community as a whole to be able to deliver a good product)
That being said, if indeed between the release cycles, a major rewrite
happens that would cause a major version bump on either side there is no
reason to couple the releases, having a shindig-{foo} 1.8, shindig-features
3.0 and a shindig-{bar} 2.0 is completely cool with me, though it might lead
to confusion too and take some explaining that they all support OpenSocial
X.Y.
