Team, I would like to start a discussion of the Usergrid release process. Licenses are being added and we are getting close to a point where we could do an official release.
In this thread, I specifically want to discuss the following: how will we handle versioning? Usergrid is a project of projects. We have many SDKs, the Admin Portal, UGC, and of course, the Stack. So what I am thinking about is how all these disparate projects will be tagged with version numbers and released. Although we may do an initial 1.0 (or maybe 2.0?) release that contains every sub-project, it seems difficult or possibly pointless to try to keep them all on the same release cadence. Developers will get work done on the different sub-projects when they have time or when they have the need. This means that each sub-project will tend progress at its own pace. The question then, is how do we ensure version compatibility between projects (e.g. how do I know that version 1.2.3 of an SDK will work with 1.3.5 of the stack)? Except for new features that we add, our API is quite stable. The API is the interface between all SDKs/the Admin Portal/UGC, and the Stack. This means that old versions of the SDKs or the Admin Portal or UGC will work with new versions of the Stack. In fact, except for one or two situations where we coded around issues in the Stack, SDK versions from 2 years ago would run against the current build of the Stack. It is a little more challenging if you go the other way. Newer versions of the SDK may have code to support features that may not have been implemented in older versions of the Stack. Question 1: how to we track this? I am thinking that each sub-project should have a page on the website where this information is displayed. The Stack merely needs to exhibit a version number. The SDKs, Admin Portal, and UGC all need to state the version of the Stack they are backwards compatible with. Remember, old SDK versions will work with new versions of the Stack, but new SDK versions may not work with old versions of the Stack. Question 2: how do we decide that a version of the code is ready for a version increment? I propose that the workflow that might look something like this: 1. Developer works on code, checks in 1 or more PRs. 2. Developer (or other committer) decides that the code that merits a version increment. 3. Developer (or other committer) proposes discussion of such on the Dev ML. 4. Once appropriate discussion has occurred, the originator calls for a vote (on a VOTE thread). 5. If vote is accepted (I think it takes 3 +1 votes?), the originator submits another PR to increment the version number wherever it is being tracked. 6. Once acked, the build is published to the appropriate page on the website along with version compatibility (and whatever other administrivia needs to occur). This workflow would allow each sub-project to progress at its own pace. It also lets discussion occur prior to a version increment. And finally, it means the sub-projects don’t impact one another unnecessarily. Thoughts? -- Rod Simpson @rockerston rodsimpson.com
