cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Independent platform release summary
Date Thu, 02 Oct 2014 23:51:23 GMT
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 <agrieve@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 <stevengill97@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 <shazron@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 <stevengill97@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!
>> > >>
>> > >
>> > >
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message