cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Gill <stevengil...@gmail.com>
Subject Re: Independent platform release summary
Date Thu, 02 Oct 2014 19:00:16 GMT
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