I don't think it's necessary to bump CLI major when platforms bump major. Platforms and CLI are linked only superficially anyways.
What do you think about: 1. Release platform 2. Blog post telling people to try it out using CLI platform add@new_version 3. After a week, bump the default platform install in CLI (the week gives some blog-post-following early adopters time to catch any mess-ups) On Thu, Oct 2, 2014 at 7:46 PM, Andrew Grieve <agri...@chromium.org> wrote: > Great write-up! Totally onboard. And like the suggestion of bumping the > major (I say either 4.0 or 10.0). > > On Thu, Oct 2, 2014 at 3:58 PM, Brian LeRoux <b...@brian.io> wrote: > >> I'm down with jumping to 4.x but not convinced a jump to 5.x would >> actually >> spur more understanding. (Also thanks for tackling this Steve.) >> >> On Thu, Oct 2, 2014 at 9:00 PM, Steven Gill <stevengil...@gmail.com> >> wrote: >> >> > I'm not opposed to a big version jump. It would draw attention to the >> fact >> > that we are changing our versioning & releasing process. How do others >> > feel? >> > >> > -Steve >> > >> > On Thu, Oct 2, 2014 at 11:45 AM, Shazron <shaz...@gmail.com> wrote: >> > >> > > 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! >> > >> >> > > >> > > >> > >> > >
