Thanks Steve for writing that up. I can definitely see the confusion in messaging, especially at the start of this new process.
So for "2) CLI + Lib version" I am proposing a radical idea (à la Windows 10) where we jump to a new version totally separate from the current 3.x series to further detach the association of the CLI version with platform versions. Version 5.x? Not sure how sem-ver kosher it is. I already have one scenario. I sent out pull requests for docs and the CLI for the new iPhone 6 icons and splash screens. These will be in the next iOS platform release 3.7.0, and if another platform didn't take 3.8.0 already, most likely CLI 3.8.0. This would mean the docs would be at 3.8.0, CLI at 3.8.0 but cordova-ios will be at 3.7.0. This is how the messaging will look like if I were to write a blog post: "To get cordova-cli support for iPhone 6 splash screens and icons, please update to cordova-cli 3.8.0, which will grab the 3.7.0 version of cordova-ios where this feature is implemented. Check out the 3.8.0 cordova-docs for usage". A bit clunky. On Thu, Oct 2, 2014 at 11:28 AM, Steven Gill <stevengil...@gmail.com> wrote: > Hey All, > > I wanted to give summary of where I believe this process is going and > answer any questions you all might have. None of this is set in stone, so > please provide feedback so we can iron this out. > > 1) Platforms can now release independently > > If iOS wants to release 3.7.0, it doesn't have to wait for other platforms > to be ready to release. Just run through > > https://github.com/apache/cordova-coho/blob/master/docs/platforms-release-process.md > and do a tools release. > > 2) CLI + Lib version will rise very quickly. > > Right now, CLI is about to be released at version 3.7.0. No platforms are > currently at version 3.7.0. Say iOS wants to release 3.7.0 next week, they > could do that, update the CLI to version 3.8.0. I suggest a platform being > released would cause the CLI to do a minor release (MAJOR.MINOR.PATCH -> > 3.8.0). But this is obviously open to discussion. > > 3) Docs > > Docs version will now be tied to CLI. If we do a major or minor release of > the CLI, docs should be regenerated to match the version of the CLI. Say > iOS 3.7.0 requires the newest version of the CLI, we can make note of that > in docs + blog post. Maybe we list the platform versions associated to CLI > somewhere in the docs? > > 4) Helping users debug > > Cordova.version & cordova.platformVersion will both return the version of > the platform, not the cli. Users can easily tell you what version of > cordova-platform they are using by doing this. Generated cordova.js files > in projects will also have this information at the top of the file along > with commit hash. > > 5) Messaging > > We need to be clear about this in our messaging to users. This is a change > from how we have been doing things and I foresee some confusion at the > beginning. Moving platforms over to package.json eventually will help users > see that platforms are independent, but we need to do more now to help > users adapt to this change. > > They need to know to expect the CLI version to jump quickly, and to know > that platform versions != cordova-cli version. > > Blog posts can list platforms cli was tested with, similarly to how we list > what plugin versions the cli was tested with when releasing. (see the > bottom of > http://cordova.apache.org/announcements/2014/09/22/cordova-361.html for an > example) > > Hopefully I didn't leave out anything major. Feedback please! >
