Thanks for feedback! I like the idea of giving our early adopters a chance to try it out and help us catch bugs, but I think that should be what RCs are for (3 day window while voting is ongoing).
How do we handle cases where the bump in platform is accompanied by a change in cordova-lib. The next iOS release has this. Anyone who wants the next iOS release will have to update their cli. If they do cordova platform add cordova-ios@nextRelease, they will run into issues with their version of cordova-lib not supporting the changes required. (Shaz can elaborate if you need, something about new splashscreen support). We have no way of preventing older cli users from trying to install newer ios other than documentation and blog post. Obviously, my above example isn't a usecase that happens every release. My goal here is to try and find a versioning policy that is easy to follow and covers as many use cases as possible. It should also follow semver. Also, noticed I had an error in my examples (the writing was fine though). CLI + Lib versioning (imagine version for cli + lib is at 4.0.0): if a platform does a patch version jump (ex ios 3.6.1), then cli + lib should do a patch jump (ex 4.0.1) If a platform does a minor version jump (ex ios 3.7.0), then cli + lib should do a minor jump (ex 4.1.0) If a platform does a major version jump (ex android 4.0.0), then cli + lib should do a major jump. (ex up to 5.0.0) On Thu, Oct 2, 2014 at 4:51 PM, Andrew Grieve <agri...@chromium.org> wrote: > 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! >>> > >> >>> > > >>> > > >>> > >>> >> >> >
