On Thu, Oct 2, 2014 at 8:12 PM, Steven Gill <stevengil...@gmail.com> wrote:
> 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. > Maybe have a minCordovaLibVersion setting in cordova-ios's package.json? > > 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! >>>> > >> >>>> > > >>>> > > >>>> > >>>> >>> >>> >> >
