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 Fri, 03 Oct 2014 13:58:01 GMT
On Thu, Oct 2, 2014 at 8:12 PM, Steven Gill <stevengill97@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 <agrieve@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 <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