To be honest, I would prefer that the version of the spec and shindig always match, otherwise I feel like we are back where we started. That being said there will be scenarios when we make minor changes to the spec that dont effect Shindig and we may need to make changes to Shindig that dont need a spec release. Maybe the best we can do is to just document this on the Shindig website. Maybe we will only be able to keep the major version numbers in sync...
From: Henry Saputra <[email protected]> To: [email protected], [email protected], Date: 02/03/2012 02:10 PM Subject: [DISCUSS] Shindig release version change to align with OpenSocial spec number Hi Shindig community, Following up from the previous discussion about Shindig version number I would like to discuss the release plan for Shindig moving forward. Since we are planning to change the next release for Shindig from 3.0.0 to 2.5.0 to align with OpenSocial spec number it currently support/implement, we need to find consistent version labeling for future Shindig releases. Give Shindig release version is following Maven format of <major>.<minor>.<revision> here is one proposal: -) The major part of the release version number should align with major version of the OpenSocial spec. -) The minor part indicates the release cycle for Shindig itself. This part does not align with the minor part of the OpenSocial spec number. -) The revision part can be used to indicate possible patches in a particular releases. For example, Since the next OpenSocial spec version released is 2.0.1, so the next Shindig number is 2.5.0. The "2" represent the major part of the OpenSocial spec number, and "5" is just release cycle for Shindig (we could actually go with 2.1 but since we have so many changes since 2.0 release thats why I proposed 2.5) and "0" is the revision number for the release. So, if after 2.5.0 we have major changes in infrastructure or implementation we could release 2.6.0. And if small patches needed in 2.5.0 that do not have big impact on how the flow executed (for example just change in JavaScript files without changes in Java or PHP code) we could just roll 2.5.1, 2.5.2, and so on. The plan is to not to make one to one mapping with OpenSocial spec number but just to align the releases so its easier to link and provide tighter relationship between spec work and the reference implementation. I know that spec number and implementation do not have to match with each other, but given how rapid the spec development release cycle and the Shindig impl itself I think this approach will work well. Any thoughts or inputs are welcomed. If this approach is acceptable I will make JIRA case for the change. Thanks, - Henry
