What's Stopping us From Independent Platform Releases

[Andrew Grieve <ag...@chromium.org>]

Wanted to start a thread for everyone to share what concrete changes they'd
like to see happen before we start having platforms being released in an
unsynchronized fashion.

I'll start :)

cordova-js:
 - cordova.version returns a value computed from the cordova-js git tag.
   - Let's deprecate this field
   - And create "cordova.platformVersion"
   - And update our release process to have the version set based on the
platform's version rather than the tag within cordova-js.

Cordova-docs:
 - Most of the docs are not actually affected by platform versions.
 - Mainly though, it's the platform guides that are.
 - Two options that I see:
   - 1) Set default version to "edge" & always annotate with "added in
X.X.X, removed in X.X.X"
   - 2) Move guides to live in platform repos and link to them from docs.

cordova-cli:
  - Set version to 4.0.0 just to make it so that it doesn't map to any
existing platform versions

Release Process:
  - Tag cordova-js for each platform release with "PLATFORM-VERSION"
  - Rewrite
https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
as "platforms-release-process"

RE: What's Stopping us From Independent Platform Releases

[Ray Camden <ra...@adobe.com>]

Freaking Outlook kinda munged my reply, so I'll keep my replies on top.

When I saw "edge", I thought that meant *post* release. Err, I mean what's coming next. I've never read "edge" as being "the current release." So if I'm wrong, and it sounds like i am,you can disregard everything I said. :)

> For either option, edge would be equivalent to latest released work. Even
if you make changes on master for cordova-docs, it wouldn't be pushed to
edge unless we were doing a docs release and the feature was being
released. This is definitely something we need to keep track of. I don't
think we have been bitten by this before though and don't imagine it being
a big problem with either option and setting default docs to edge.

Moving platform docs to platform repos and grabbing them at build time for
docs would hopefully prevent this type of situation from arising.



> Please, please, please do not do this.
>
> Why can't the docs simply be updated w/o updating the bits? Is that really
> the case? If so, fix *that* bug.
>

I'm not sure I understand what you mean by above? The reason we are needing
to switch docs is because we are not doing cadence releases after 3.6.0. So
either we have docs live with no version or we version it along side the
CLI. Ex. CLI could be at version 5, cordova-firefox could be at version
3.7.0, cordova-android could be at version 4.2, etc. What would the
versions of docs be?


>
>
> ________________________________________
> From: Steven Gill <st...@gmail.com>
> Sent: Wednesday, August 20, 2014 3:59 PM
> To: dev@cordova.apache.org
> Subject: Re: What's Stopping us From Independent Platform Releases
>
> I still feel it would be a mistake to stop versioning our docs. It would
> confuse our users.  It is a norm for projects to have docs associated to
> specific versions.
>
> I think docs should be versioned when the cli gets released and
> docs.cordova.io should always point to edge. This would address the
> splashscreen docs not being live even though the feature has shipped.
>
> This use case can also handle us introducing breaking changes (ex: android
> 4.0) and not have to keep older docs on edge.
>
> Annotating with "supported in android 3.6.0+" can start looking very ugly
> over time if we have lots of annotations all over the place.
>
> As for previous versions, bugs most likely won't be fixed unless it is
> something someone volunteers to do. I don't see much value in updating old
> versions of docs. But it is worth still having them available for people
> using those versions.
>
> I'd like to hear what others think about this?
>
> Both proposals are described at
> https://issues.apache.org/jira/browse/CB-7226
>

Re: What's Stopping us From Independent Platform Releases

[Steven Gill <st...@gmail.com>]

Sounds good to me regarding docs.

I am going to start pushing my changes to cordova-js, cordova-lib, and
cordova-coho now. I am planning on testing out the process for indy
releases by doing a release for the browser platform. I will start up a
discuss thread when I am ready to do that.

-Steve

On Mon, Sep 8, 2014 at 6:55 PM, Andrew Grieve <ag...@chromium.org> wrote:

> Splitting out the docs would be really tough for some things:
> - cross-cutting: "Platform support", "Icons & Splashscreens"
> - Generic in nature: "Privacy Guide", "Security Guide", etc
>
> Handling translations is also a pain the more we extract things out.
>
> Having CLI create pre-project docs is a neat idea, but online is where
> people look.
>
> So.... I think I've warmed up to the idea of generating new docs for
> each CLI release. For platform-specific things, we'll still need to
> say when features are introduced though, since updating your CLI
> doesn't mean you've updating your platforms.
>
> I think we'll need to have our docs generation de-dupe images assets
> instead of creating copies for each version / language since that's
> 99% of the file size in the repo.
>
>
>
>
>
>
> On Wed, Aug 20, 2014 at 9:59 PM, Carlos Santana <cs...@gmail.com>
> wrote:
> > Yes Ray, that's what I meant as a new Design for the Docs website. To be
> a
> > consolidated simple view of the docs, but the real docs will be
> associated
> > with each component as an implementation detail.
> >
> > It can also be a consolidated view of docs as utility of the cordova CLI,
> > for example "$cordova docs" launches a local web server, open the
> browser,
> > and serves a local website with the content coming form the versions of
> the
> > things being used in your cordova project/folder (ios, plugin1, plugin2)
> >
> > We need to try different things, get feedback and iterate
> >
> > And feedback from coming form developers such as yourself.
> >
> > --Carlos
> >
> >
> >
> >
> > On Wed, Aug 20, 2014 at 8:58 PM, Ray Camden <ra...@adobe.com> wrote:
> >
> >> Keep in mind - the average developer probably has no idea what
> >> cordova-ios, cordova-cli, and cordova-lib means. They npm install
> cordova,
> >> and to them, that's it.
> >> ________________________________________
> >> From: Carlos Santana <cs...@gmail.com>
> >> Sent: Wednesday, August 20, 2014 7:54 PM
> >> To: dev@cordova.apache.org
> >> Subject: Re: What's Stopping us From Independent Platform Releases
> >>
> >> I think we need to come down to the same conclusion as we did for
> plugins.
> >> The documentation for each "component" meaning "cordova-ios",
> >> "cordova-cli", "cordova-lib" needs to live with it's repo/code and
> version
> >> together.
> >>
> >> The remaining things can be left in cordova-docs that are independent
> of a
> >> version of a component to an extent like security guide.
> >>
> >> The Cordova Docs Website will need to have a new UX design to make
> sense of
> >> where links point and somehow allow the user know what's the latest
> release
> >> and the different components with each respective version.
> >>
> >>
> >>
> >
> >
> > --
> > Carlos Santana
> > <cs...@gmail.com>
>

Re: What's Stopping us From Independent Platform Releases

[Andrew Grieve <ag...@chromium.org>]

Splitting out the docs would be really tough for some things:
- cross-cutting: "Platform support", "Icons & Splashscreens"
- Generic in nature: "Privacy Guide", "Security Guide", etc

Handling translations is also a pain the more we extract things out.

Having CLI create pre-project docs is a neat idea, but online is where
people look.

So.... I think I've warmed up to the idea of generating new docs for
each CLI release. For platform-specific things, we'll still need to
say when features are introduced though, since updating your CLI
doesn't mean you've updating your platforms.

I think we'll need to have our docs generation de-dupe images assets
instead of creating copies for each version / language since that's
99% of the file size in the repo.






On Wed, Aug 20, 2014 at 9:59 PM, Carlos Santana <cs...@gmail.com> wrote:
> Yes Ray, that's what I meant as a new Design for the Docs website. To be a
> consolidated simple view of the docs, but the real docs will be associated
> with each component as an implementation detail.
>
> It can also be a consolidated view of docs as utility of the cordova CLI,
> for example "$cordova docs" launches a local web server, open the browser,
> and serves a local website with the content coming form the versions of the
> things being used in your cordova project/folder (ios, plugin1, plugin2)
>
> We need to try different things, get feedback and iterate
>
> And feedback from coming form developers such as yourself.
>
> --Carlos
>
>
>
>
> On Wed, Aug 20, 2014 at 8:58 PM, Ray Camden <ra...@adobe.com> wrote:
>
>> Keep in mind - the average developer probably has no idea what
>> cordova-ios, cordova-cli, and cordova-lib means. They npm install cordova,
>> and to them, that's it.
>> ________________________________________
>> From: Carlos Santana <cs...@gmail.com>
>> Sent: Wednesday, August 20, 2014 7:54 PM
>> To: dev@cordova.apache.org
>> Subject: Re: What's Stopping us From Independent Platform Releases
>>
>> I think we need to come down to the same conclusion as we did for plugins.
>> The documentation for each "component" meaning "cordova-ios",
>> "cordova-cli", "cordova-lib" needs to live with it's repo/code and version
>> together.
>>
>> The remaining things can be left in cordova-docs that are independent of a
>> version of a component to an extent like security guide.
>>
>> The Cordova Docs Website will need to have a new UX design to make sense of
>> where links point and somehow allow the user know what's the latest release
>> and the different components with each respective version.
>>
>>
>>
>
>
> --
> Carlos Santana
> <cs...@gmail.com>

Re: What's Stopping us From Independent Platform Releases

[Carlos Santana <cs...@gmail.com>]

Yes Ray, that's what I meant as a new Design for the Docs website. To be a
consolidated simple view of the docs, but the real docs will be associated
with each component as an implementation detail.

It can also be a consolidated view of docs as utility of the cordova CLI,
for example "$cordova docs" launches a local web server, open the browser,
and serves a local website with the content coming form the versions of the
things being used in your cordova project/folder (ios, plugin1, plugin2)

We need to try different things, get feedback and iterate

And feedback from coming form developers such as yourself.

--Carlos




On Wed, Aug 20, 2014 at 8:58 PM, Ray Camden <ra...@adobe.com> wrote:

> Keep in mind - the average developer probably has no idea what
> cordova-ios, cordova-cli, and cordova-lib means. They npm install cordova,
> and to them, that's it.
> ________________________________________
> From: Carlos Santana <cs...@gmail.com>
> Sent: Wednesday, August 20, 2014 7:54 PM
> To: dev@cordova.apache.org
> Subject: Re: What's Stopping us From Independent Platform Releases
>
> I think we need to come down to the same conclusion as we did for plugins.
> The documentation for each "component" meaning "cordova-ios",
> "cordova-cli", "cordova-lib" needs to live with it's repo/code and version
> together.
>
> The remaining things can be left in cordova-docs that are independent of a
> version of a component to an extent like security guide.
>
> The Cordova Docs Website will need to have a new UX design to make sense of
> where links point and somehow allow the user know what's the latest release
> and the different components with each respective version.
>
>
>


-- 
Carlos Santana
<cs...@gmail.com>

RE: What's Stopping us From Independent Platform Releases

[Ray Camden <ra...@adobe.com>]

Keep in mind - the average developer probably has no idea what cordova-ios, cordova-cli, and cordova-lib means. They npm install cordova, and to them, that's it. 
________________________________________
From: Carlos Santana <cs...@gmail.com>
Sent: Wednesday, August 20, 2014 7:54 PM
To: dev@cordova.apache.org
Subject: Re: What's Stopping us From Independent Platform Releases

I think we need to come down to the same conclusion as we did for plugins.
The documentation for each "component" meaning "cordova-ios",
"cordova-cli", "cordova-lib" needs to live with it's repo/code and version
together.

The remaining things can be left in cordova-docs that are independent of a
version of a component to an extent like security guide.

The Cordova Docs Website will need to have a new UX design to make sense of
where links point and somehow allow the user know what's the latest release
and the different components with each respective version.

Re: What's Stopping us From Independent Platform Releases

[Carlos Santana <cs...@gmail.com>]

I think we need to come down to the same conclusion as we did for plugins.
The documentation for each "component" meaning "cordova-ios",
"cordova-cli", "cordova-lib" needs to live with it's repo/code and version
together.

The remaining things can be left in cordova-docs that are independent of a
version of a component to an extent like security guide.

The Cordova Docs Website will need to have a new UX design to make sense of
where links point and somehow allow the user know what's the latest release
and the different components with each respective version.




On Wed, Aug 20, 2014 at 6:49 PM, Steven Gill <st...@gmail.com> wrote:

> Thanks for the input Ray!
>
>
>
> On Wednesday, August 20, 2014, Ray Camden <ra...@adobe.com> wrote:
>
> > I'll echo the issues I raised before. If the docs say that so and so is
> > supported, but it is for edge and not the current release, I think that
> > would be a huge mistake. I consider myself a pretty good Cordova dev and
> I
> > think even I would be confused as well. (I almost never run anything but
> > the released version so I can be sure what I blog, help folks with, etc,
> > matches the released version.)
> >
> > For either option, edge would be equivalent to latest released work. Even
> if you make changes on master for cordova-docs, it wouldn't be pushed to
> edge unless we were doing a docs release and the feature was being
> released. This is definitely something we need to keep track of. I don't
> think we have been bitten by this before though and don't imagine it being
> a big problem with either option and setting default docs to edge.
>
> Moving platform docs to platform repos and grabbing them at build time for
> docs would hopefully prevent this type of situation from arising.
>
>
>
> > Please, please, please do not do this.
> >
> > Why can't the docs simply be updated w/o updating the bits? Is that
> really
> > the case? If so, fix *that* bug.
> >
>
> I'm not sure I understand what you mean by above? The reason we are needing
> to switch docs is because we are not doing cadence releases after 3.6.0. So
> either we have docs live with no version or we version it along side the
> CLI. Ex. CLI could be at version 5, cordova-firefox could be at version
> 3.7.0, cordova-android could be at version 4.2, etc. What would the
> versions of docs be?
>
>
> >
> >
> > ________________________________________
> > From: Steven Gill <st...@gmail.com>
> > Sent: Wednesday, August 20, 2014 3:59 PM
> > To: dev@cordova.apache.org
> > Subject: Re: What's Stopping us From Independent Platform Releases
> >
> > I still feel it would be a mistake to stop versioning our docs. It would
> > confuse our users.  It is a norm for projects to have docs associated to
> > specific versions.
> >
> > I think docs should be versioned when the cli gets released and
> > docs.cordova.io should always point to edge. This would address the
> > splashscreen docs not being live even though the feature has shipped.
> >
> > This use case can also handle us introducing breaking changes (ex:
> android
> > 4.0) and not have to keep older docs on edge.
> >
> > Annotating with "supported in android 3.6.0+" can start looking very ugly
> > over time if we have lots of annotations all over the place.
> >
> > As for previous versions, bugs most likely won't be fixed unless it is
> > something someone volunteers to do. I don't see much value in updating
> old
> > versions of docs. But it is worth still having them available for people
> > using those versions.
> >
> > I'd like to hear what others think about this?
> >
> > Both proposals are described at
> > https://issues.apache.org/jira/browse/CB-7226
> >
>



-- 
Carlos Santana
<cs...@gmail.com>

Re: What's Stopping us From Independent Platform Releases

[Steven Gill <st...@gmail.com>]

Thanks for the input Ray!



On Wednesday, August 20, 2014, Ray Camden <ra...@adobe.com> wrote:

> I'll echo the issues I raised before. If the docs say that so and so is
> supported, but it is for edge and not the current release, I think that
> would be a huge mistake. I consider myself a pretty good Cordova dev and I
> think even I would be confused as well. (I almost never run anything but
> the released version so I can be sure what I blog, help folks with, etc,
> matches the released version.)
>
> For either option, edge would be equivalent to latest released work. Even
if you make changes on master for cordova-docs, it wouldn't be pushed to
edge unless we were doing a docs release and the feature was being
released. This is definitely something we need to keep track of. I don't
think we have been bitten by this before though and don't imagine it being
a big problem with either option and setting default docs to edge.

Moving platform docs to platform repos and grabbing them at build time for
docs would hopefully prevent this type of situation from arising.



> Please, please, please do not do this.
>
> Why can't the docs simply be updated w/o updating the bits? Is that really
> the case? If so, fix *that* bug.
>

I'm not sure I understand what you mean by above? The reason we are needing
to switch docs is because we are not doing cadence releases after 3.6.0. So
either we have docs live with no version or we version it along side the
CLI. Ex. CLI could be at version 5, cordova-firefox could be at version
3.7.0, cordova-android could be at version 4.2, etc. What would the
versions of docs be?


>
>
> ________________________________________
> From: Steven Gill <st...@gmail.com>
> Sent: Wednesday, August 20, 2014 3:59 PM
> To: dev@cordova.apache.org
> Subject: Re: What's Stopping us From Independent Platform Releases
>
> I still feel it would be a mistake to stop versioning our docs. It would
> confuse our users.  It is a norm for projects to have docs associated to
> specific versions.
>
> I think docs should be versioned when the cli gets released and
> docs.cordova.io should always point to edge. This would address the
> splashscreen docs not being live even though the feature has shipped.
>
> This use case can also handle us introducing breaking changes (ex: android
> 4.0) and not have to keep older docs on edge.
>
> Annotating with "supported in android 3.6.0+" can start looking very ugly
> over time if we have lots of annotations all over the place.
>
> As for previous versions, bugs most likely won't be fixed unless it is
> something someone volunteers to do. I don't see much value in updating old
> versions of docs. But it is worth still having them available for people
> using those versions.
>
> I'd like to hear what others think about this?
>
> Both proposals are described at
> https://issues.apache.org/jira/browse/CB-7226
>

RE: What's Stopping us From Independent Platform Releases

[Ray Camden <ra...@adobe.com>]

I'll echo the issues I raised before. If the docs say that so and so is supported, but it is for edge and not the current release, I think that would be a huge mistake. I consider myself a pretty good Cordova dev and I think even I would be confused as well. (I almost never run anything but the released version so I can be sure what I blog, help folks with, etc, matches the released version.)

Please, please, please do not do this. 

Why can't the docs simply be updated w/o updating the bits? Is that really the case? If so, fix *that* bug.


________________________________________
From: Steven Gill <st...@gmail.com>
Sent: Wednesday, August 20, 2014 3:59 PM
To: dev@cordova.apache.org
Subject: Re: What's Stopping us From Independent Platform Releases

I still feel it would be a mistake to stop versioning our docs. It would
confuse our users.  It is a norm for projects to have docs associated to
specific versions.

I think docs should be versioned when the cli gets released and
docs.cordova.io should always point to edge. This would address the
splashscreen docs not being live even though the feature has shipped.

This use case can also handle us introducing breaking changes (ex: android
4.0) and not have to keep older docs on edge.

Annotating with "supported in android 3.6.0+" can start looking very ugly
over time if we have lots of annotations all over the place.

As for previous versions, bugs most likely won't be fixed unless it is
something someone volunteers to do. I don't see much value in updating old
versions of docs. But it is worth still having them available for people
using those versions.

I'd like to hear what others think about this?

Both proposals are described at
https://issues.apache.org/jira/browse/CB-7226

Re: What's Stopping us From Independent Platform Releases

[Steven Gill <st...@gmail.com>]

I still feel it would be a mistake to stop versioning our docs. It would
confuse our users.  It is a norm for projects to have docs associated to
specific versions.

I think docs should be versioned when the cli gets released and
docs.cordova.io should always point to edge. This would address the
splashscreen docs not being live even though the feature has shipped.

This use case can also handle us introducing breaking changes (ex: android
4.0) and not have to keep older docs on edge.

Annotating with "supported in android 3.6.0+" can start looking very ugly
over time if we have lots of annotations all over the place.

As for previous versions, bugs most likely won't be fixed unless it is
something someone volunteers to do. I don't see much value in updating old
versions of docs. But it is worth still having them available for people
using those versions.

I'd like to hear what others think about this?

Both proposals are described at
https://issues.apache.org/jira/browse/CB-7226


On Wed, Aug 20, 2014 at 1:02 PM, Andrew Grieve <ag...@chromium.org> wrote:

> Just did some pull requests for docs, and wanted to share that I think
> there is really good reason to stop versioning our docs.
>
> - One PR fixed broken links in the 3.5.0 docs that pointed to plugin
> dev branches.
>   --> Any external links in versioned docs may break at any time!
> - One PR was for the new splashscreen support in cordova-lib
>   --> This won't make it out until the next platform release, even
> though it's a shipped feature in CLI!
>
> Versioning our docs has some merit, but it also causes old versions of
> docs to have bugs that don't get fixed, and it adds delays to new
> docs.
>
> Because the things we are documenting are released & versioned
> separately, I think the only sane path forward is to stop versioning
> the docs (and annotate with "supported in android 3.6.0+").
>
> On Thu, Aug 14, 2014 at 5:28 PM, Brian LeRoux <b...@brian.io> wrote:
> > Yes, that email was very clearly very rushed! Too much on my plate.
> >
> > The ./bin/create scripts generate 'platform' projects. We need to keep
> > those. They each should use a common seed template for www assets.
> Ideally
> > the platform knows about icons and splashscreens too, so higher level
> > abstracts only need to pass those things down to the platforms. I have no
> > idea where we are with that part. Its always been a headache and one of
> the
> > things keeping ./platforms in version control.
> >
> > Higher up the chain I think we should break out the 'create' part of
> > cordova-lib into a completely separate module that other downstream
> things
> > can use. For example, with PhoneGap Developer Apps you don't need the
> > entire CLI (or any native bits) but just a create command and the
> > phonegap-connect modules for serving the content to the app (app harness
> > flow too).
> >
> >
> >
> >
> > On Thu, Aug 14, 2014 at 12:59 PM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> >
> >> Could you elaborate Brian? Do you mean to stop support bin/create
> scripts?
> >> Or to have all platforms node-depend on a templates module? Have one
> module
> >> vs one-template-per-platform? Does this apply to both
> icons/splashscreens
> >> as well as default www/?
> >>
> >>
> >> On Thu, Aug 14, 2014 at 3:45 PM, Carlos Santana <cs...@gmail.com>
> >> wrote:
> >>
> >> > +1 one way of doing it
> >> >
> >> >
> >> > On Thu, Aug 14, 2014 at 1:21 PM, Brian LeRoux <b...@brian.io> wrote:
> >> >
> >> > > rather than bundle app-hello-world I'd rather we *extracted*
> >> > > cordova-project-create from cordova-lib into its own module so thing
> >> that
> >> > > create cordova projects only have one way of doing it
> >> > >
> >> > >
> >> > >
> >> > > On Thu, Aug 14, 2014 at 7:58 AM, Carlos Santana <
> csantana23@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > Each platform should carry their default contents including set of
> >> > icons
> >> > > > and screens for none CLI workflow, the platform can keep taking
> them
> >> > from
> >> > > > app-hello-world as part of it's independent platform release.
> >> > > >
> >> > > > For app-hello-world it should be tag and release with the tools
> (CLI
> >> > > > release) as it's use as the default template for "create"
> >> > > >
> >> > > > Now that I think CLI and config.xml supports icons and screens,
> the
> >> > > default
> >> > > > app created by CLI should include the "res/" icons and screens,
> >> > > including a
> >> > > > config.xml configured with proper values pointing to the images.
> >> > > > This will be easier to end user to figure out on disk what files
> it
> >> > needs
> >> > > > to be modified in the "res/" directory on CLI project.
> >> > > >
> >> > > > This can also be optimized that "res/" contents get populated as
> the
> >> > > > "cordova platform add" gets executed so user only gets in "res/"
> and
> >> > > > "config.xml" only the platforms added.
> >> > > >
> >> > > > I was looking into this recently as I'm trying to create a new
> >> > universal
> >> > > > www template for IBM Worklight to be use by cordova CLI, but I got
> >> > brain
> >> > > > stop on how do I create a git repo that includes all my default
> icons
> >> > and
> >> > > > screens that user will replace, but don't want to pollute their
> >> cordova
> >> > > > project with images from a platform their not dealing with yet,
> and
> >> how
> >> > > to
> >> > > > add those icons and screens when they do an "platform add" for a
> new
> >> > > > platform.
> >> > > >
> >> > > > Maybe this deserves a new thread.
> >> > > >
> >> > > > net is that app-hello-world should be release tad with tools not
> >> > > platforms
> >> > > > releases.
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Thu, Aug 14, 2014 at 9:48 AM, Michal Mocny <
> mmocny@chromium.org>
> >> > > wrote:
> >> > > >
> >> > > > > Does hello-world even need to be versioned at all, then?  Its
> just
> >> > part
> >> > > > of
> >> > > > > the platform/cli release, and its assets are voted on as part of
> >> > that?
> >> > > > >
> >> > > > >
> >> > > > > On Thu, Aug 14, 2014 at 9:43 AM, Andrew Grieve <
> >> agrieve@chromium.org
> >> > >
> >> > > > > wrote:
> >> > > > >
> >> > > > > > app-hello-world is quite a weird one now. There's two parts to
> >> it:
> >> > > > > > 1) default icons & splashscreens - copied into each platform
> >> > > > > > 2) default www/ - copied into each platform & into
> lazy_load'ed
> >> by
> >> > > CLI
> >> > > > > >
> >> > > > > > For 2) - I think we should stop lazy loading. Maybe just copy
> it
> >> > into
> >> > > > the
> >> > > > > > CLI repo.
> >> > > > > >
> >> > > > > > For versioning though - I think the repo should be tagged /
> >> > versioned
> >> > > > > > independently whenever it makes sense.
> >> > > > > >
> >> > > > > >
> >> > > > > > On Thu, Aug 14, 2014 at 9:16 AM, Ian Clelland <
> >> > > iclelland@chromium.org>
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > > > Currently, mobile-spec needs to be tagged with platform
> >> versions,
> >> > > > since
> >> > > > > > it
> >> > > > > > > contains tests for those platforms, outside of the plugin
> tests
> >> > > (like
> >> > > > > the
> >> > > > > > > bridge and whitelist tests). As soon as we can move those
> out,
> >> > then
> >> > > > > > > mobilespec becomes a generic test runner for Cordova, and we
> >> can
> >> > > just
> >> > > > > tag
> >> > > > > > > it independently of platforms.
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > On Wed, Aug 13, 2014 at 6:12 PM, Steven Gill <
> >> > > stevengill97@gmail.com
> >> > > > >
> >> > > > > > > wrote:
> >> > > > > > >
> >> > > > > > > > New question
> >> > > > > > > >
> >> > > > > > > > How does tagging and versioning for
> cordova-app-hello-world
> >> and
> >> > > > > > > > cordova-mobile-spec look in this new world of independent
> >> > > releases?
> >> > > > > > > >
> >> > > > > > > > Currently:
> >> > > > > > > >
> >> > > > > > > > 1) They both get branched and tagged at the beginning of a
> >> > > cadence
> >> > > > > > > release.
> >> > > > > > > > 2) The hello world app is supposed to be manually copied
> to
> >> > > > platforms
> >> > > > > > if
> >> > > > > > > > changes exist.
> >> > > > > > > >
> >> > > > > > > > Suggestions:
> >> > > > > > > >
> >> > > > > > > > A) They both get tagged independently of platforms. Won't
> >> > happen
> >> > > > > often
> >> > > > > > > > unless they are changing (the app rarely changes).
> >> > > > > > > >
> >> > > > > > > > B) They get tagged platform-version when doing a release.
> So
> >> > > mobile
> >> > > > > > spec
> >> > > > > > > > would have a tag android-3.6.0 when we are doing the 3.6.0
> >> > > release.
> >> > > > > > > >
> >> > > > > > > > I think we should stop branching for these two repos.
> Doesn't
> >> > add
> >> > > > > much
> >> > > > > > > > value. The tag will take us back to the state when the
> >> platform
> >> > > was
> >> > > > > > > > released.
> >> > > > > > > >
> >> > > > > > > > Thoughts? Other suggestions?
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > > On Fri, Aug 8, 2014 at 11:26 AM, Andrew Grieve <
> >> > > > agrieve@chromium.org
> >> > > > > >
> >> > > > > > > > wrote:
> >> > > > > > > >
> >> > > > > > > > > On Tue, Jul 29, 2014 at 5:00 PM, Steven Gill <
> >> > > > > stevengill97@gmail.com
> >> > > > > > >
> >> > > > > > > > > wrote:
> >> > > > > > > > >
> >> > > > > > > > > > Started creating issues to keep track of all of these
> >> > things.
> >> > > > > > > > > >
> >> > > > > > > > > > Master issue can be seen at
> >> > > > > > > > > https://issues.apache.org/jira/browse/CB-7221
> >> > > > > > > > > >
> >> > > > > > > > > > Setting CLI to version 4.0.0 sounds good to me. We can
> >> > > mention
> >> > > > in
> >> > > > > > the
> >> > > > > > > > > > release blog post how platforms are on their own
> schedule
> >> > > now.
> >> > > > > > > > > >
> >> > > > > > > > > > Option 3 for docs
> >> > > > > > > > > > - Docs get same version as CLI & get tagged alongside
> cli
> >> > > > > releases
> >> > > > > > > > > > - We can still annotate with "added in X.X.X, removed
> in
> >> > > X.X.X"
> >> > > > > > where
> >> > > > > > > > it
> >> > > > > > > > > > makes sense. (like the upgrade guides)
> >> > > > > > > > > > - Point docs.cordova.io to edge
> >> > > > > > > > > > - Dropdown will show tagged versions
> >> > > > > > > > > > Pros:
> >> > > > > > > > > > - Keeps a public history of older docs at a point in
> >> time.
> >> > > Easy
> >> > > > > to
> >> > > > > > > use
> >> > > > > > > > > for
> >> > > > > > > > > > people who don't want the latest
> >> > > > > > > > > > - Gives us flexibility in changing docs and not
> worrying
> >> > > about
> >> > > > > > older
> >> > > > > > > > > > versions.
> >> > > > > > > > > >
> >> > > > > > > > > > Thoughts?
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > Each new version of the docs has significant space
> >> > requirements
> >> > > > > since
> >> > > > > > > we
> >> > > > > > > > > don't de-dupe images across versions or translations.
> Not
> >> the
> >> > > end
> >> > > > > of
> >> > > > > > > the
> >> > > > > > > > > world, but the repo is already > 1GB, so it is annoying.
> >> > > > > > > > >
> >> > > > > > > > > I don't think it's common that we delete docs, so maybe
> we
> >> > > could
> >> > > > > just
> >> > > > > > > > > create new versions when we do purges? Otherwise, the
> old
> >> > > > versions
> >> > > > > of
> >> > > > > > > > docs
> >> > > > > > > > > just have bugs and are strictly worse than the newest
> set,
> >> I
> >> > > > think.
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > > -Steve
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > > > On Mon, Jul 28, 2014 at 8:26 AM, Michal Mocny <
> >> > > > > mmocny@chromium.org
> >> > > > > > >
> >> > > > > > > > > wrote:
> >> > > > > > > > > >
> >> > > > > > > > > > > On Mon, Jul 28, 2014 at 5:41 AM, Gorkem Ercan <
> >> > > > > > > > gorkem.ercan@gmail.com>
> >> > > > > > > > > > > wrote:
> >> > > > > > > > > > >
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > This has been discussed long enough and even for
> >> those
> >> > > > > > downstream
> >> > > > > > > > > > > > distros and tools who will have to adjust, it is
> >> better
> >> > > to
> >> > > > > > > finalize
> >> > > > > > > > > it.
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > Overall I like the plan, my major concern was with
> >> > > cadence
> >> > > > > > > > releaeses
> >> > > > > > > > > > > gone,
> >> > > > > > > > > > > > the lack of a
> >> > > > > > > > > > > > name/tag/version number for Cordova, and a
> >> description
> >> > of
> >> > > > its
> >> > > > > > > > > contents.
> >> > > > > > > > > > > > Now, this is
> >> > > > > > > > > > > > addressed with CLI and package.json file.
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > My +1 for this.
> >> > > > > > > > > > > >
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > On Fri, Jul 25, 2014 at 05:25:28PM -0400, Andrew
> >> Grieve
> >> > > > > wrote:
> >> > > > > > > > > > > > > Wanted to start a thread for everyone to share
> what
> >> > > > > concrete
> >> > > > > > > > > changes
> >> > > > > > > > > > > > they'd
> >> > > > > > > > > > > > > like to see happen before we start having
> platforms
> >> > > being
> >> > > > > > > > released
> >> > > > > > > > > in
> >> > > > > > > > > > > an
> >> > > > > > > > > > > > > unsynchronized fashion.
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > I'll start :)
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > cordova-js:
> >> > > > > > > > > > > > >  - cordova.version returns a value computed from
> >> the
> >> > > > > > cordova-js
> >> > > > > > > > git
> >> > > > > > > > > > > tag.
> >> > > > > > > > > > > > >    - Let's deprecate this field
> >> > > > > > > > > > > > >    - And create "cordova.platformVersion"
> >> > > > > > > > > > > > >    - And update our release process to have the
> >> > version
> >> > > > set
> >> > > > > > > based
> >> > > > > > > > > on
> >> > > > > > > > > > > the
> >> > > > > > > > > > > > > platform's version rather than the tag within
> >> > > cordova-js.
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > What will be the value for cordova.version during
> >> > > > deprecation
> >> > > > > > > > period?
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > Cordova-docs:
> >> > > > > > > > > > > > >  - Most of the docs are not actually affected by
> >> > > platform
> >> > > > > > > > versions.
> >> > > > > > > > > > > > >  - Mainly though, it's the platform guides that
> >> are.
> >> > > > > > > > > > > > >  - Two options that I see:
> >> > > > > > > > > > > > >    - 1) Set default version to "edge" & always
> >> > annotate
> >> > > > > with
> >> > > > > > > > "added
> >> > > > > > > > > > in
> >> > > > > > > > > > > > > X.X.X, removed in X.X.X"
> >> > > > > > > > > > > > >    - 2) Move guides to live in platform repos
> and
> >> > link
> >> > > to
> >> > > > > > them
> >> > > > > > > > from
> >> > > > > > > > > > > docs.
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > cordova-cli:
> >> > > > > > > > > > > > >   - Set version to 4.0.0 just to make it so
> that it
> >> > > > doesn't
> >> > > > > > map
> >> > > > > > > > to
> >> > > > > > > > > > any
> >> > > > > > > > > > > > > existing platform versions
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > Not sure if this matters. Platforms will catch up
> to
> >> > > 4.0.0
> >> > > > > soon
> >> > > > > > > > > enough.
> >> > > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > > > CLI version is currently "3.5.0-0.2.7-dev".  We
> need to
> >> > > > change
> >> > > > > it
> >> > > > > > > to
> >> > > > > > > > > > > something thats valid semver, and preferably
> somewhat
> >> > > > > compatible
> >> > > > > > > with
> >> > > > > > > > > the
> >> > > > > > > > > > > previous versions.  Choices I think are:
> >> > > > > > > > > > > - 3.6.0
> >> > > > > > > > > > > - 4.0.0
> >> > > > > > > > > > > - A Complete reset
> >> > > > > > > > > > >
> >> > > > > > > > > > > I'm also in favour of 4.0.0 given those options.
> >> > > > > > > > > > >
> >> > > > > > > > > > > I am mildly concerned that with the looming 4.0
> >> releases
> >> > of
> >> > > > > > > > platforms,
> >> > > > > > > > > > > users will think this is a cad-ver update and not
> >> > > appreciate
> >> > > > > the
> >> > > > > > > > change
> >> > > > > > > > > > of
> >> > > > > > > > > > > strategy, but partially think that may be a good
> thing
> >> > too
> >> > > > > (slow
> >> > > > > > > > > > > comfortable transition).
> >> > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > > > >
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > > > Release Process:
> >> > > > > > > > > > > > >   - Tag cordova-js for each platform release
> with
> >> > > > > > > > > "PLATFORM-VERSION"
> >> > > > > > > > > > > > >   - Rewrite
> >> > > > > > > > > > > > >
> >> > > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
> >> > > > > > > > > > > > > as "platforms-release-process"
> >> > > > > > > > > > > >
> >> > > > > > > > > > >
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Carlos Santana
> >> > > > <cs...@gmail.com>
> >> > > >
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Carlos Santana
> >> > <cs...@gmail.com>
> >> >
> >>
>

Re: What's Stopping us From Independent Platform Releases

[Andrew Grieve <ag...@chromium.org>]

Just did some pull requests for docs, and wanted to share that I think
there is really good reason to stop versioning our docs.

- One PR fixed broken links in the 3.5.0 docs that pointed to plugin
dev branches.
  --> Any external links in versioned docs may break at any time!
- One PR was for the new splashscreen support in cordova-lib
  --> This won't make it out until the next platform release, even
though it's a shipped feature in CLI!

Versioning our docs has some merit, but it also causes old versions of
docs to have bugs that don't get fixed, and it adds delays to new
docs.

Because the things we are documenting are released & versioned
separately, I think the only sane path forward is to stop versioning
the docs (and annotate with "supported in android 3.6.0+").

On Thu, Aug 14, 2014 at 5:28 PM, Brian LeRoux <b...@brian.io> wrote:
> Yes, that email was very clearly very rushed! Too much on my plate.
>
> The ./bin/create scripts generate 'platform' projects. We need to keep
> those. They each should use a common seed template for www assets. Ideally
> the platform knows about icons and splashscreens too, so higher level
> abstracts only need to pass those things down to the platforms. I have no
> idea where we are with that part. Its always been a headache and one of the
> things keeping ./platforms in version control.
>
> Higher up the chain I think we should break out the 'create' part of
> cordova-lib into a completely separate module that other downstream things
> can use. For example, with PhoneGap Developer Apps you don't need the
> entire CLI (or any native bits) but just a create command and the
> phonegap-connect modules for serving the content to the app (app harness
> flow too).
>
>
>
>
> On Thu, Aug 14, 2014 at 12:59 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
>> Could you elaborate Brian? Do you mean to stop support bin/create scripts?
>> Or to have all platforms node-depend on a templates module? Have one module
>> vs one-template-per-platform? Does this apply to both icons/splashscreens
>> as well as default www/?
>>
>>
>> On Thu, Aug 14, 2014 at 3:45 PM, Carlos Santana <cs...@gmail.com>
>> wrote:
>>
>> > +1 one way of doing it
>> >
>> >
>> > On Thu, Aug 14, 2014 at 1:21 PM, Brian LeRoux <b...@brian.io> wrote:
>> >
>> > > rather than bundle app-hello-world I'd rather we *extracted*
>> > > cordova-project-create from cordova-lib into its own module so thing
>> that
>> > > create cordova projects only have one way of doing it
>> > >
>> > >
>> > >
>> > > On Thu, Aug 14, 2014 at 7:58 AM, Carlos Santana <cs...@gmail.com>
>> > > wrote:
>> > >
>> > > > Each platform should carry their default contents including set of
>> > icons
>> > > > and screens for none CLI workflow, the platform can keep taking them
>> > from
>> > > > app-hello-world as part of it's independent platform release.
>> > > >
>> > > > For app-hello-world it should be tag and release with the tools (CLI
>> > > > release) as it's use as the default template for "create"
>> > > >
>> > > > Now that I think CLI and config.xml supports icons and screens, the
>> > > default
>> > > > app created by CLI should include the "res/" icons and screens,
>> > > including a
>> > > > config.xml configured with proper values pointing to the images.
>> > > > This will be easier to end user to figure out on disk what files it
>> > needs
>> > > > to be modified in the "res/" directory on CLI project.
>> > > >
>> > > > This can also be optimized that "res/" contents get populated as the
>> > > > "cordova platform add" gets executed so user only gets in "res/" and
>> > > > "config.xml" only the platforms added.
>> > > >
>> > > > I was looking into this recently as I'm trying to create a new
>> > universal
>> > > > www template for IBM Worklight to be use by cordova CLI, but I got
>> > brain
>> > > > stop on how do I create a git repo that includes all my default icons
>> > and
>> > > > screens that user will replace, but don't want to pollute their
>> cordova
>> > > > project with images from a platform their not dealing with yet, and
>> how
>> > > to
>> > > > add those icons and screens when they do an "platform add" for a new
>> > > > platform.
>> > > >
>> > > > Maybe this deserves a new thread.
>> > > >
>> > > > net is that app-hello-world should be release tad with tools not
>> > > platforms
>> > > > releases.
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On Thu, Aug 14, 2014 at 9:48 AM, Michal Mocny <mm...@chromium.org>
>> > > wrote:
>> > > >
>> > > > > Does hello-world even need to be versioned at all, then?  Its just
>> > part
>> > > > of
>> > > > > the platform/cli release, and its assets are voted on as part of
>> > that?
>> > > > >
>> > > > >
>> > > > > On Thu, Aug 14, 2014 at 9:43 AM, Andrew Grieve <
>> agrieve@chromium.org
>> > >
>> > > > > wrote:
>> > > > >
>> > > > > > app-hello-world is quite a weird one now. There's two parts to
>> it:
>> > > > > > 1) default icons & splashscreens - copied into each platform
>> > > > > > 2) default www/ - copied into each platform & into lazy_load'ed
>> by
>> > > CLI
>> > > > > >
>> > > > > > For 2) - I think we should stop lazy loading. Maybe just copy it
>> > into
>> > > > the
>> > > > > > CLI repo.
>> > > > > >
>> > > > > > For versioning though - I think the repo should be tagged /
>> > versioned
>> > > > > > independently whenever it makes sense.
>> > > > > >
>> > > > > >
>> > > > > > On Thu, Aug 14, 2014 at 9:16 AM, Ian Clelland <
>> > > iclelland@chromium.org>
>> > > > > > wrote:
>> > > > > >
>> > > > > > > Currently, mobile-spec needs to be tagged with platform
>> versions,
>> > > > since
>> > > > > > it
>> > > > > > > contains tests for those platforms, outside of the plugin tests
>> > > (like
>> > > > > the
>> > > > > > > bridge and whitelist tests). As soon as we can move those out,
>> > then
>> > > > > > > mobilespec becomes a generic test runner for Cordova, and we
>> can
>> > > just
>> > > > > tag
>> > > > > > > it independently of platforms.
>> > > > > > >
>> > > > > > >
>> > > > > > > On Wed, Aug 13, 2014 at 6:12 PM, Steven Gill <
>> > > stevengill97@gmail.com
>> > > > >
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > > > New question
>> > > > > > > >
>> > > > > > > > How does tagging and versioning for cordova-app-hello-world
>> and
>> > > > > > > > cordova-mobile-spec look in this new world of independent
>> > > releases?
>> > > > > > > >
>> > > > > > > > Currently:
>> > > > > > > >
>> > > > > > > > 1) They both get branched and tagged at the beginning of a
>> > > cadence
>> > > > > > > release.
>> > > > > > > > 2) The hello world app is supposed to be manually copied to
>> > > > platforms
>> > > > > > if
>> > > > > > > > changes exist.
>> > > > > > > >
>> > > > > > > > Suggestions:
>> > > > > > > >
>> > > > > > > > A) They both get tagged independently of platforms. Won't
>> > happen
>> > > > > often
>> > > > > > > > unless they are changing (the app rarely changes).
>> > > > > > > >
>> > > > > > > > B) They get tagged platform-version when doing a release. So
>> > > mobile
>> > > > > > spec
>> > > > > > > > would have a tag android-3.6.0 when we are doing the 3.6.0
>> > > release.
>> > > > > > > >
>> > > > > > > > I think we should stop branching for these two repos. Doesn't
>> > add
>> > > > > much
>> > > > > > > > value. The tag will take us back to the state when the
>> platform
>> > > was
>> > > > > > > > released.
>> > > > > > > >
>> > > > > > > > Thoughts? Other suggestions?
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > On Fri, Aug 8, 2014 at 11:26 AM, Andrew Grieve <
>> > > > agrieve@chromium.org
>> > > > > >
>> > > > > > > > wrote:
>> > > > > > > >
>> > > > > > > > > On Tue, Jul 29, 2014 at 5:00 PM, Steven Gill <
>> > > > > stevengill97@gmail.com
>> > > > > > >
>> > > > > > > > > wrote:
>> > > > > > > > >
>> > > > > > > > > > Started creating issues to keep track of all of these
>> > things.
>> > > > > > > > > >
>> > > > > > > > > > Master issue can be seen at
>> > > > > > > > > https://issues.apache.org/jira/browse/CB-7221
>> > > > > > > > > >
>> > > > > > > > > > Setting CLI to version 4.0.0 sounds good to me. We can
>> > > mention
>> > > > in
>> > > > > > the
>> > > > > > > > > > release blog post how platforms are on their own schedule
>> > > now.
>> > > > > > > > > >
>> > > > > > > > > > Option 3 for docs
>> > > > > > > > > > - Docs get same version as CLI & get tagged alongside cli
>> > > > > releases
>> > > > > > > > > > - We can still annotate with "added in X.X.X, removed in
>> > > X.X.X"
>> > > > > > where
>> > > > > > > > it
>> > > > > > > > > > makes sense. (like the upgrade guides)
>> > > > > > > > > > - Point docs.cordova.io to edge
>> > > > > > > > > > - Dropdown will show tagged versions
>> > > > > > > > > > Pros:
>> > > > > > > > > > - Keeps a public history of older docs at a point in
>> time.
>> > > Easy
>> > > > > to
>> > > > > > > use
>> > > > > > > > > for
>> > > > > > > > > > people who don't want the latest
>> > > > > > > > > > - Gives us flexibility in changing docs and not worrying
>> > > about
>> > > > > > older
>> > > > > > > > > > versions.
>> > > > > > > > > >
>> > > > > > > > > > Thoughts?
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > Each new version of the docs has significant space
>> > requirements
>> > > > > since
>> > > > > > > we
>> > > > > > > > > don't de-dupe images across versions or translations. Not
>> the
>> > > end
>> > > > > of
>> > > > > > > the
>> > > > > > > > > world, but the repo is already > 1GB, so it is annoying.
>> > > > > > > > >
>> > > > > > > > > I don't think it's common that we delete docs, so maybe we
>> > > could
>> > > > > just
>> > > > > > > > > create new versions when we do purges? Otherwise, the old
>> > > > versions
>> > > > > of
>> > > > > > > > docs
>> > > > > > > > > just have bugs and are strictly worse than the newest set,
>> I
>> > > > think.
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > -Steve
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > On Mon, Jul 28, 2014 at 8:26 AM, Michal Mocny <
>> > > > > mmocny@chromium.org
>> > > > > > >
>> > > > > > > > > wrote:
>> > > > > > > > > >
>> > > > > > > > > > > On Mon, Jul 28, 2014 at 5:41 AM, Gorkem Ercan <
>> > > > > > > > gorkem.ercan@gmail.com>
>> > > > > > > > > > > wrote:
>> > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > > > This has been discussed long enough and even for
>> those
>> > > > > > downstream
>> > > > > > > > > > > > distros and tools who will have to adjust, it is
>> better
>> > > to
>> > > > > > > finalize
>> > > > > > > > > it.
>> > > > > > > > > > > >
>> > > > > > > > > > > > Overall I like the plan, my major concern was with
>> > > cadence
>> > > > > > > > releaeses
>> > > > > > > > > > > gone,
>> > > > > > > > > > > > the lack of a
>> > > > > > > > > > > > name/tag/version number for Cordova, and a
>> description
>> > of
>> > > > its
>> > > > > > > > > contents.
>> > > > > > > > > > > > Now, this is
>> > > > > > > > > > > > addressed with CLI and package.json file.
>> > > > > > > > > > > >
>> > > > > > > > > > > > My +1 for this.
>> > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > > > On Fri, Jul 25, 2014 at 05:25:28PM -0400, Andrew
>> Grieve
>> > > > > wrote:
>> > > > > > > > > > > > > Wanted to start a thread for everyone to share what
>> > > > > concrete
>> > > > > > > > > changes
>> > > > > > > > > > > > they'd
>> > > > > > > > > > > > > like to see happen before we start having platforms
>> > > being
>> > > > > > > > released
>> > > > > > > > > in
>> > > > > > > > > > > an
>> > > > > > > > > > > > > unsynchronized fashion.
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > I'll start :)
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > cordova-js:
>> > > > > > > > > > > > >  - cordova.version returns a value computed from
>> the
>> > > > > > cordova-js
>> > > > > > > > git
>> > > > > > > > > > > tag.
>> > > > > > > > > > > > >    - Let's deprecate this field
>> > > > > > > > > > > > >    - And create "cordova.platformVersion"
>> > > > > > > > > > > > >    - And update our release process to have the
>> > version
>> > > > set
>> > > > > > > based
>> > > > > > > > > on
>> > > > > > > > > > > the
>> > > > > > > > > > > > > platform's version rather than the tag within
>> > > cordova-js.
>> > > > > > > > > > > >
>> > > > > > > > > > > > What will be the value for cordova.version during
>> > > > deprecation
>> > > > > > > > period?
>> > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > Cordova-docs:
>> > > > > > > > > > > > >  - Most of the docs are not actually affected by
>> > > platform
>> > > > > > > > versions.
>> > > > > > > > > > > > >  - Mainly though, it's the platform guides that
>> are.
>> > > > > > > > > > > > >  - Two options that I see:
>> > > > > > > > > > > > >    - 1) Set default version to "edge" & always
>> > annotate
>> > > > > with
>> > > > > > > > "added
>> > > > > > > > > > in
>> > > > > > > > > > > > > X.X.X, removed in X.X.X"
>> > > > > > > > > > > > >    - 2) Move guides to live in platform repos and
>> > link
>> > > to
>> > > > > > them
>> > > > > > > > from
>> > > > > > > > > > > docs.
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > cordova-cli:
>> > > > > > > > > > > > >   - Set version to 4.0.0 just to make it so that it
>> > > > doesn't
>> > > > > > map
>> > > > > > > > to
>> > > > > > > > > > any
>> > > > > > > > > > > > > existing platform versions
>> > > > > > > > > > > >
>> > > > > > > > > > > > Not sure if this matters. Platforms will catch up to
>> > > 4.0.0
>> > > > > soon
>> > > > > > > > > enough.
>> > > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > > > CLI version is currently "3.5.0-0.2.7-dev".  We need to
>> > > > change
>> > > > > it
>> > > > > > > to
>> > > > > > > > > > > something thats valid semver, and preferably somewhat
>> > > > > compatible
>> > > > > > > with
>> > > > > > > > > the
>> > > > > > > > > > > previous versions.  Choices I think are:
>> > > > > > > > > > > - 3.6.0
>> > > > > > > > > > > - 4.0.0
>> > > > > > > > > > > - A Complete reset
>> > > > > > > > > > >
>> > > > > > > > > > > I'm also in favour of 4.0.0 given those options.
>> > > > > > > > > > >
>> > > > > > > > > > > I am mildly concerned that with the looming 4.0
>> releases
>> > of
>> > > > > > > > platforms,
>> > > > > > > > > > > users will think this is a cad-ver update and not
>> > > appreciate
>> > > > > the
>> > > > > > > > change
>> > > > > > > > > > of
>> > > > > > > > > > > strategy, but partially think that may be a good thing
>> > too
>> > > > > (slow
>> > > > > > > > > > > comfortable transition).
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > > > >
>> > > > > > > > > > > > > Release Process:
>> > > > > > > > > > > > >   - Tag cordova-js for each platform release with
>> > > > > > > > > "PLATFORM-VERSION"
>> > > > > > > > > > > > >   - Rewrite
>> > > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
>> > > > > > > > > > > > > as "platforms-release-process"
>> > > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Carlos Santana
>> > > > <cs...@gmail.com>
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > Carlos Santana
>> > <cs...@gmail.com>
>> >
>>

Re: What's Stopping us From Independent Platform Releases

[Brian LeRoux <b...@brian.io>]

Yes, that email was very clearly very rushed! Too much on my plate.

The ./bin/create scripts generate 'platform' projects. We need to keep
those. They each should use a common seed template for www assets. Ideally
the platform knows about icons and splashscreens too, so higher level
abstracts only need to pass those things down to the platforms. I have no
idea where we are with that part. Its always been a headache and one of the
things keeping ./platforms in version control.

Higher up the chain I think we should break out the 'create' part of
cordova-lib into a completely separate module that other downstream things
can use. For example, with PhoneGap Developer Apps you don't need the
entire CLI (or any native bits) but just a create command and the
phonegap-connect modules for serving the content to the app (app harness
flow too).




On Thu, Aug 14, 2014 at 12:59 PM, Andrew Grieve <ag...@chromium.org>
wrote:

> Could you elaborate Brian? Do you mean to stop support bin/create scripts?
> Or to have all platforms node-depend on a templates module? Have one module
> vs one-template-per-platform? Does this apply to both icons/splashscreens
> as well as default www/?
>
>
> On Thu, Aug 14, 2014 at 3:45 PM, Carlos Santana <cs...@gmail.com>
> wrote:
>
> > +1 one way of doing it
> >
> >
> > On Thu, Aug 14, 2014 at 1:21 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > rather than bundle app-hello-world I'd rather we *extracted*
> > > cordova-project-create from cordova-lib into its own module so thing
> that
> > > create cordova projects only have one way of doing it
> > >
> > >
> > >
> > > On Thu, Aug 14, 2014 at 7:58 AM, Carlos Santana <cs...@gmail.com>
> > > wrote:
> > >
> > > > Each platform should carry their default contents including set of
> > icons
> > > > and screens for none CLI workflow, the platform can keep taking them
> > from
> > > > app-hello-world as part of it's independent platform release.
> > > >
> > > > For app-hello-world it should be tag and release with the tools (CLI
> > > > release) as it's use as the default template for "create"
> > > >
> > > > Now that I think CLI and config.xml supports icons and screens, the
> > > default
> > > > app created by CLI should include the "res/" icons and screens,
> > > including a
> > > > config.xml configured with proper values pointing to the images.
> > > > This will be easier to end user to figure out on disk what files it
> > needs
> > > > to be modified in the "res/" directory on CLI project.
> > > >
> > > > This can also be optimized that "res/" contents get populated as the
> > > > "cordova platform add" gets executed so user only gets in "res/" and
> > > > "config.xml" only the platforms added.
> > > >
> > > > I was looking into this recently as I'm trying to create a new
> > universal
> > > > www template for IBM Worklight to be use by cordova CLI, but I got
> > brain
> > > > stop on how do I create a git repo that includes all my default icons
> > and
> > > > screens that user will replace, but don't want to pollute their
> cordova
> > > > project with images from a platform their not dealing with yet, and
> how
> > > to
> > > > add those icons and screens when they do an "platform add" for a new
> > > > platform.
> > > >
> > > > Maybe this deserves a new thread.
> > > >
> > > > net is that app-hello-world should be release tad with tools not
> > > platforms
> > > > releases.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Aug 14, 2014 at 9:48 AM, Michal Mocny <mm...@chromium.org>
> > > wrote:
> > > >
> > > > > Does hello-world even need to be versioned at all, then?  Its just
> > part
> > > > of
> > > > > the platform/cli release, and its assets are voted on as part of
> > that?
> > > > >
> > > > >
> > > > > On Thu, Aug 14, 2014 at 9:43 AM, Andrew Grieve <
> agrieve@chromium.org
> > >
> > > > > wrote:
> > > > >
> > > > > > app-hello-world is quite a weird one now. There's two parts to
> it:
> > > > > > 1) default icons & splashscreens - copied into each platform
> > > > > > 2) default www/ - copied into each platform & into lazy_load'ed
> by
> > > CLI
> > > > > >
> > > > > > For 2) - I think we should stop lazy loading. Maybe just copy it
> > into
> > > > the
> > > > > > CLI repo.
> > > > > >
> > > > > > For versioning though - I think the repo should be tagged /
> > versioned
> > > > > > independently whenever it makes sense.
> > > > > >
> > > > > >
> > > > > > On Thu, Aug 14, 2014 at 9:16 AM, Ian Clelland <
> > > iclelland@chromium.org>
> > > > > > wrote:
> > > > > >
> > > > > > > Currently, mobile-spec needs to be tagged with platform
> versions,
> > > > since
> > > > > > it
> > > > > > > contains tests for those platforms, outside of the plugin tests
> > > (like
> > > > > the
> > > > > > > bridge and whitelist tests). As soon as we can move those out,
> > then
> > > > > > > mobilespec becomes a generic test runner for Cordova, and we
> can
> > > just
> > > > > tag
> > > > > > > it independently of platforms.
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Aug 13, 2014 at 6:12 PM, Steven Gill <
> > > stevengill97@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > New question
> > > > > > > >
> > > > > > > > How does tagging and versioning for cordova-app-hello-world
> and
> > > > > > > > cordova-mobile-spec look in this new world of independent
> > > releases?
> > > > > > > >
> > > > > > > > Currently:
> > > > > > > >
> > > > > > > > 1) They both get branched and tagged at the beginning of a
> > > cadence
> > > > > > > release.
> > > > > > > > 2) The hello world app is supposed to be manually copied to
> > > > platforms
> > > > > > if
> > > > > > > > changes exist.
> > > > > > > >
> > > > > > > > Suggestions:
> > > > > > > >
> > > > > > > > A) They both get tagged independently of platforms. Won't
> > happen
> > > > > often
> > > > > > > > unless they are changing (the app rarely changes).
> > > > > > > >
> > > > > > > > B) They get tagged platform-version when doing a release. So
> > > mobile
> > > > > > spec
> > > > > > > > would have a tag android-3.6.0 when we are doing the 3.6.0
> > > release.
> > > > > > > >
> > > > > > > > I think we should stop branching for these two repos. Doesn't
> > add
> > > > > much
> > > > > > > > value. The tag will take us back to the state when the
> platform
> > > was
> > > > > > > > released.
> > > > > > > >
> > > > > > > > Thoughts? Other suggestions?
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Aug 8, 2014 at 11:26 AM, Andrew Grieve <
> > > > agrieve@chromium.org
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Tue, Jul 29, 2014 at 5:00 PM, Steven Gill <
> > > > > stevengill97@gmail.com
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Started creating issues to keep track of all of these
> > things.
> > > > > > > > > >
> > > > > > > > > > Master issue can be seen at
> > > > > > > > > https://issues.apache.org/jira/browse/CB-7221
> > > > > > > > > >
> > > > > > > > > > Setting CLI to version 4.0.0 sounds good to me. We can
> > > mention
> > > > in
> > > > > > the
> > > > > > > > > > release blog post how platforms are on their own schedule
> > > now.
> > > > > > > > > >
> > > > > > > > > > Option 3 for docs
> > > > > > > > > > - Docs get same version as CLI & get tagged alongside cli
> > > > > releases
> > > > > > > > > > - We can still annotate with "added in X.X.X, removed in
> > > X.X.X"
> > > > > > where
> > > > > > > > it
> > > > > > > > > > makes sense. (like the upgrade guides)
> > > > > > > > > > - Point docs.cordova.io to edge
> > > > > > > > > > - Dropdown will show tagged versions
> > > > > > > > > > Pros:
> > > > > > > > > > - Keeps a public history of older docs at a point in
> time.
> > > Easy
> > > > > to
> > > > > > > use
> > > > > > > > > for
> > > > > > > > > > people who don't want the latest
> > > > > > > > > > - Gives us flexibility in changing docs and not worrying
> > > about
> > > > > > older
> > > > > > > > > > versions.
> > > > > > > > > >
> > > > > > > > > > Thoughts?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Each new version of the docs has significant space
> > requirements
> > > > > since
> > > > > > > we
> > > > > > > > > don't de-dupe images across versions or translations. Not
> the
> > > end
> > > > > of
> > > > > > > the
> > > > > > > > > world, but the repo is already > 1GB, so it is annoying.
> > > > > > > > >
> > > > > > > > > I don't think it's common that we delete docs, so maybe we
> > > could
> > > > > just
> > > > > > > > > create new versions when we do purges? Otherwise, the old
> > > > versions
> > > > > of
> > > > > > > > docs
> > > > > > > > > just have bugs and are strictly worse than the newest set,
> I
> > > > think.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > -Steve
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Mon, Jul 28, 2014 at 8:26 AM, Michal Mocny <
> > > > > mmocny@chromium.org
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > On Mon, Jul 28, 2014 at 5:41 AM, Gorkem Ercan <
> > > > > > > > gorkem.ercan@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > This has been discussed long enough and even for
> those
> > > > > > downstream
> > > > > > > > > > > > distros and tools who will have to adjust, it is
> better
> > > to
> > > > > > > finalize
> > > > > > > > > it.
> > > > > > > > > > > >
> > > > > > > > > > > > Overall I like the plan, my major concern was with
> > > cadence
> > > > > > > > releaeses
> > > > > > > > > > > gone,
> > > > > > > > > > > > the lack of a
> > > > > > > > > > > > name/tag/version number for Cordova, and a
> description
> > of
> > > > its
> > > > > > > > > contents.
> > > > > > > > > > > > Now, this is
> > > > > > > > > > > > addressed with CLI and package.json file.
> > > > > > > > > > > >
> > > > > > > > > > > > My +1 for this.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Jul 25, 2014 at 05:25:28PM -0400, Andrew
> Grieve
> > > > > wrote:
> > > > > > > > > > > > > Wanted to start a thread for everyone to share what
> > > > > concrete
> > > > > > > > > changes
> > > > > > > > > > > > they'd
> > > > > > > > > > > > > like to see happen before we start having platforms
> > > being
> > > > > > > > released
> > > > > > > > > in
> > > > > > > > > > > an
> > > > > > > > > > > > > unsynchronized fashion.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'll start :)
> > > > > > > > > > > > >
> > > > > > > > > > > > > cordova-js:
> > > > > > > > > > > > >  - cordova.version returns a value computed from
> the
> > > > > > cordova-js
> > > > > > > > git
> > > > > > > > > > > tag.
> > > > > > > > > > > > >    - Let's deprecate this field
> > > > > > > > > > > > >    - And create "cordova.platformVersion"
> > > > > > > > > > > > >    - And update our release process to have the
> > version
> > > > set
> > > > > > > based
> > > > > > > > > on
> > > > > > > > > > > the
> > > > > > > > > > > > > platform's version rather than the tag within
> > > cordova-js.
> > > > > > > > > > > >
> > > > > > > > > > > > What will be the value for cordova.version during
> > > > deprecation
> > > > > > > > period?
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Cordova-docs:
> > > > > > > > > > > > >  - Most of the docs are not actually affected by
> > > platform
> > > > > > > > versions.
> > > > > > > > > > > > >  - Mainly though, it's the platform guides that
> are.
> > > > > > > > > > > > >  - Two options that I see:
> > > > > > > > > > > > >    - 1) Set default version to "edge" & always
> > annotate
> > > > > with
> > > > > > > > "added
> > > > > > > > > > in
> > > > > > > > > > > > > X.X.X, removed in X.X.X"
> > > > > > > > > > > > >    - 2) Move guides to live in platform repos and
> > link
> > > to
> > > > > > them
> > > > > > > > from
> > > > > > > > > > > docs.
> > > > > > > > > > > > >
> > > > > > > > > > > > > cordova-cli:
> > > > > > > > > > > > >   - Set version to 4.0.0 just to make it so that it
> > > > doesn't
> > > > > > map
> > > > > > > > to
> > > > > > > > > > any
> > > > > > > > > > > > > existing platform versions
> > > > > > > > > > > >
> > > > > > > > > > > > Not sure if this matters. Platforms will catch up to
> > > 4.0.0
> > > > > soon
> > > > > > > > > enough.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > CLI version is currently "3.5.0-0.2.7-dev".  We need to
> > > > change
> > > > > it
> > > > > > > to
> > > > > > > > > > > something thats valid semver, and preferably somewhat
> > > > > compatible
> > > > > > > with
> > > > > > > > > the
> > > > > > > > > > > previous versions.  Choices I think are:
> > > > > > > > > > > - 3.6.0
> > > > > > > > > > > - 4.0.0
> > > > > > > > > > > - A Complete reset
> > > > > > > > > > >
> > > > > > > > > > > I'm also in favour of 4.0.0 given those options.
> > > > > > > > > > >
> > > > > > > > > > > I am mildly concerned that with the looming 4.0
> releases
> > of
> > > > > > > > platforms,
> > > > > > > > > > > users will think this is a cad-ver update and not
> > > appreciate
> > > > > the
> > > > > > > > change
> > > > > > > > > > of
> > > > > > > > > > > strategy, but partially think that may be a good thing
> > too
> > > > > (slow
> > > > > > > > > > > comfortable transition).
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Release Process:
> > > > > > > > > > > > >   - Tag cordova-js for each platform release with
> > > > > > > > > "PLATFORM-VERSION"
> > > > > > > > > > > > >   - Rewrite
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
> > > > > > > > > > > > > as "platforms-release-process"
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Carlos Santana
> > > > <cs...@gmail.com>
> > > >
> > >
> >
> >
> >
> > --
> > Carlos Santana
> > <cs...@gmail.com>
> >
>

Re: What's Stopping us From Independent Platform Releases

[Andrew Grieve <ag...@chromium.org>]

Could you elaborate Brian? Do you mean to stop support bin/create scripts?
Or to have all platforms node-depend on a templates module? Have one module
vs one-template-per-platform? Does this apply to both icons/splashscreens
as well as default www/?


On Thu, Aug 14, 2014 at 3:45 PM, Carlos Santana <cs...@gmail.com>
wrote:

> +1 one way of doing it
>
>
> On Thu, Aug 14, 2014 at 1:21 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > rather than bundle app-hello-world I'd rather we *extracted*
> > cordova-project-create from cordova-lib into its own module so thing that
> > create cordova projects only have one way of doing it
> >
> >
> >
> > On Thu, Aug 14, 2014 at 7:58 AM, Carlos Santana <cs...@gmail.com>
> > wrote:
> >
> > > Each platform should carry their default contents including set of
> icons
> > > and screens for none CLI workflow, the platform can keep taking them
> from
> > > app-hello-world as part of it's independent platform release.
> > >
> > > For app-hello-world it should be tag and release with the tools (CLI
> > > release) as it's use as the default template for "create"
> > >
> > > Now that I think CLI and config.xml supports icons and screens, the
> > default
> > > app created by CLI should include the "res/" icons and screens,
> > including a
> > > config.xml configured with proper values pointing to the images.
> > > This will be easier to end user to figure out on disk what files it
> needs
> > > to be modified in the "res/" directory on CLI project.
> > >
> > > This can also be optimized that "res/" contents get populated as the
> > > "cordova platform add" gets executed so user only gets in "res/" and
> > > "config.xml" only the platforms added.
> > >
> > > I was looking into this recently as I'm trying to create a new
> universal
> > > www template for IBM Worklight to be use by cordova CLI, but I got
> brain
> > > stop on how do I create a git repo that includes all my default icons
> and
> > > screens that user will replace, but don't want to pollute their cordova
> > > project with images from a platform their not dealing with yet, and how
> > to
> > > add those icons and screens when they do an "platform add" for a new
> > > platform.
> > >
> > > Maybe this deserves a new thread.
> > >
> > > net is that app-hello-world should be release tad with tools not
> > platforms
> > > releases.
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Aug 14, 2014 at 9:48 AM, Michal Mocny <mm...@chromium.org>
> > wrote:
> > >
> > > > Does hello-world even need to be versioned at all, then?  Its just
> part
> > > of
> > > > the platform/cli release, and its assets are voted on as part of
> that?
> > > >
> > > >
> > > > On Thu, Aug 14, 2014 at 9:43 AM, Andrew Grieve <agrieve@chromium.org
> >
> > > > wrote:
> > > >
> > > > > app-hello-world is quite a weird one now. There's two parts to it:
> > > > > 1) default icons & splashscreens - copied into each platform
> > > > > 2) default www/ - copied into each platform & into lazy_load'ed by
> > CLI
> > > > >
> > > > > For 2) - I think we should stop lazy loading. Maybe just copy it
> into
> > > the
> > > > > CLI repo.
> > > > >
> > > > > For versioning though - I think the repo should be tagged /
> versioned
> > > > > independently whenever it makes sense.
> > > > >
> > > > >
> > > > > On Thu, Aug 14, 2014 at 9:16 AM, Ian Clelland <
> > iclelland@chromium.org>
> > > > > wrote:
> > > > >
> > > > > > Currently, mobile-spec needs to be tagged with platform versions,
> > > since
> > > > > it
> > > > > > contains tests for those platforms, outside of the plugin tests
> > (like
> > > > the
> > > > > > bridge and whitelist tests). As soon as we can move those out,
> then
> > > > > > mobilespec becomes a generic test runner for Cordova, and we can
> > just
> > > > tag
> > > > > > it independently of platforms.
> > > > > >
> > > > > >
> > > > > > On Wed, Aug 13, 2014 at 6:12 PM, Steven Gill <
> > stevengill97@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > New question
> > > > > > >
> > > > > > > How does tagging and versioning for cordova-app-hello-world and
> > > > > > > cordova-mobile-spec look in this new world of independent
> > releases?
> > > > > > >
> > > > > > > Currently:
> > > > > > >
> > > > > > > 1) They both get branched and tagged at the beginning of a
> > cadence
> > > > > > release.
> > > > > > > 2) The hello world app is supposed to be manually copied to
> > > platforms
> > > > > if
> > > > > > > changes exist.
> > > > > > >
> > > > > > > Suggestions:
> > > > > > >
> > > > > > > A) They both get tagged independently of platforms. Won't
> happen
> > > > often
> > > > > > > unless they are changing (the app rarely changes).
> > > > > > >
> > > > > > > B) They get tagged platform-version when doing a release. So
> > mobile
> > > > > spec
> > > > > > > would have a tag android-3.6.0 when we are doing the 3.6.0
> > release.
> > > > > > >
> > > > > > > I think we should stop branching for these two repos. Doesn't
> add
> > > > much
> > > > > > > value. The tag will take us back to the state when the platform
> > was
> > > > > > > released.
> > > > > > >
> > > > > > > Thoughts? Other suggestions?
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Aug 8, 2014 at 11:26 AM, Andrew Grieve <
> > > agrieve@chromium.org
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Tue, Jul 29, 2014 at 5:00 PM, Steven Gill <
> > > > stevengill97@gmail.com
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Started creating issues to keep track of all of these
> things.
> > > > > > > > >
> > > > > > > > > Master issue can be seen at
> > > > > > > > https://issues.apache.org/jira/browse/CB-7221
> > > > > > > > >
> > > > > > > > > Setting CLI to version 4.0.0 sounds good to me. We can
> > mention
> > > in
> > > > > the
> > > > > > > > > release blog post how platforms are on their own schedule
> > now.
> > > > > > > > >
> > > > > > > > > Option 3 for docs
> > > > > > > > > - Docs get same version as CLI & get tagged alongside cli
> > > > releases
> > > > > > > > > - We can still annotate with "added in X.X.X, removed in
> > X.X.X"
> > > > > where
> > > > > > > it
> > > > > > > > > makes sense. (like the upgrade guides)
> > > > > > > > > - Point docs.cordova.io to edge
> > > > > > > > > - Dropdown will show tagged versions
> > > > > > > > > Pros:
> > > > > > > > > - Keeps a public history of older docs at a point in time.
> > Easy
> > > > to
> > > > > > use
> > > > > > > > for
> > > > > > > > > people who don't want the latest
> > > > > > > > > - Gives us flexibility in changing docs and not worrying
> > about
> > > > > older
> > > > > > > > > versions.
> > > > > > > > >
> > > > > > > > > Thoughts?
> > > > > > > > >
> > > > > > > >
> > > > > > > > Each new version of the docs has significant space
> requirements
> > > > since
> > > > > > we
> > > > > > > > don't de-dupe images across versions or translations. Not the
> > end
> > > > of
> > > > > > the
> > > > > > > > world, but the repo is already > 1GB, so it is annoying.
> > > > > > > >
> > > > > > > > I don't think it's common that we delete docs, so maybe we
> > could
> > > > just
> > > > > > > > create new versions when we do purges? Otherwise, the old
> > > versions
> > > > of
> > > > > > > docs
> > > > > > > > just have bugs and are strictly worse than the newest set, I
> > > think.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > -Steve
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, Jul 28, 2014 at 8:26 AM, Michal Mocny <
> > > > mmocny@chromium.org
> > > > > >
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > On Mon, Jul 28, 2014 at 5:41 AM, Gorkem Ercan <
> > > > > > > gorkem.ercan@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > This has been discussed long enough and even for those
> > > > > downstream
> > > > > > > > > > > distros and tools who will have to adjust, it is better
> > to
> > > > > > finalize
> > > > > > > > it.
> > > > > > > > > > >
> > > > > > > > > > > Overall I like the plan, my major concern was with
> > cadence
> > > > > > > releaeses
> > > > > > > > > > gone,
> > > > > > > > > > > the lack of a
> > > > > > > > > > > name/tag/version number for Cordova, and a description
> of
> > > its
> > > > > > > > contents.
> > > > > > > > > > > Now, this is
> > > > > > > > > > > addressed with CLI and package.json file.
> > > > > > > > > > >
> > > > > > > > > > > My +1 for this.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Jul 25, 2014 at 05:25:28PM -0400, Andrew Grieve
> > > > wrote:
> > > > > > > > > > > > Wanted to start a thread for everyone to share what
> > > > concrete
> > > > > > > > changes
> > > > > > > > > > > they'd
> > > > > > > > > > > > like to see happen before we start having platforms
> > being
> > > > > > > released
> > > > > > > > in
> > > > > > > > > > an
> > > > > > > > > > > > unsynchronized fashion.
> > > > > > > > > > > >
> > > > > > > > > > > > I'll start :)
> > > > > > > > > > > >
> > > > > > > > > > > > cordova-js:
> > > > > > > > > > > >  - cordova.version returns a value computed from the
> > > > > cordova-js
> > > > > > > git
> > > > > > > > > > tag.
> > > > > > > > > > > >    - Let's deprecate this field
> > > > > > > > > > > >    - And create "cordova.platformVersion"
> > > > > > > > > > > >    - And update our release process to have the
> version
> > > set
> > > > > > based
> > > > > > > > on
> > > > > > > > > > the
> > > > > > > > > > > > platform's version rather than the tag within
> > cordova-js.
> > > > > > > > > > >
> > > > > > > > > > > What will be the value for cordova.version during
> > > deprecation
> > > > > > > period?
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Cordova-docs:
> > > > > > > > > > > >  - Most of the docs are not actually affected by
> > platform
> > > > > > > versions.
> > > > > > > > > > > >  - Mainly though, it's the platform guides that are.
> > > > > > > > > > > >  - Two options that I see:
> > > > > > > > > > > >    - 1) Set default version to "edge" & always
> annotate
> > > > with
> > > > > > > "added
> > > > > > > > > in
> > > > > > > > > > > > X.X.X, removed in X.X.X"
> > > > > > > > > > > >    - 2) Move guides to live in platform repos and
> link
> > to
> > > > > them
> > > > > > > from
> > > > > > > > > > docs.
> > > > > > > > > > > >
> > > > > > > > > > > > cordova-cli:
> > > > > > > > > > > >   - Set version to 4.0.0 just to make it so that it
> > > doesn't
> > > > > map
> > > > > > > to
> > > > > > > > > any
> > > > > > > > > > > > existing platform versions
> > > > > > > > > > >
> > > > > > > > > > > Not sure if this matters. Platforms will catch up to
> > 4.0.0
> > > > soon
> > > > > > > > enough.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > CLI version is currently "3.5.0-0.2.7-dev".  We need to
> > > change
> > > > it
> > > > > > to
> > > > > > > > > > something thats valid semver, and preferably somewhat
> > > > compatible
> > > > > > with
> > > > > > > > the
> > > > > > > > > > previous versions.  Choices I think are:
> > > > > > > > > > - 3.6.0
> > > > > > > > > > - 4.0.0
> > > > > > > > > > - A Complete reset
> > > > > > > > > >
> > > > > > > > > > I'm also in favour of 4.0.0 given those options.
> > > > > > > > > >
> > > > > > > > > > I am mildly concerned that with the looming 4.0 releases
> of
> > > > > > > platforms,
> > > > > > > > > > users will think this is a cad-ver update and not
> > appreciate
> > > > the
> > > > > > > change
> > > > > > > > > of
> > > > > > > > > > strategy, but partially think that may be a good thing
> too
> > > > (slow
> > > > > > > > > > comfortable transition).
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Release Process:
> > > > > > > > > > > >   - Tag cordova-js for each platform release with
> > > > > > > > "PLATFORM-VERSION"
> > > > > > > > > > > >   - Rewrite
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
> > > > > > > > > > > > as "platforms-release-process"
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Carlos Santana
> > > <cs...@gmail.com>
> > >
> >
>
>
>
> --
> Carlos Santana
> <cs...@gmail.com>
>

Re: What's Stopping us From Independent Platform Releases

[Carlos Santana <cs...@gmail.com>]

+1 one way of doing it


On Thu, Aug 14, 2014 at 1:21 PM, Brian LeRoux <b...@brian.io> wrote:

> rather than bundle app-hello-world I'd rather we *extracted*
> cordova-project-create from cordova-lib into its own module so thing that
> create cordova projects only have one way of doing it
>
>
>
> On Thu, Aug 14, 2014 at 7:58 AM, Carlos Santana <cs...@gmail.com>
> wrote:
>
> > Each platform should carry their default contents including set of icons
> > and screens for none CLI workflow, the platform can keep taking them from
> > app-hello-world as part of it's independent platform release.
> >
> > For app-hello-world it should be tag and release with the tools (CLI
> > release) as it's use as the default template for "create"
> >
> > Now that I think CLI and config.xml supports icons and screens, the
> default
> > app created by CLI should include the "res/" icons and screens,
> including a
> > config.xml configured with proper values pointing to the images.
> > This will be easier to end user to figure out on disk what files it needs
> > to be modified in the "res/" directory on CLI project.
> >
> > This can also be optimized that "res/" contents get populated as the
> > "cordova platform add" gets executed so user only gets in "res/" and
> > "config.xml" only the platforms added.
> >
> > I was looking into this recently as I'm trying to create a new universal
> > www template for IBM Worklight to be use by cordova CLI, but I got brain
> > stop on how do I create a git repo that includes all my default icons and
> > screens that user will replace, but don't want to pollute their cordova
> > project with images from a platform their not dealing with yet, and how
> to
> > add those icons and screens when they do an "platform add" for a new
> > platform.
> >
> > Maybe this deserves a new thread.
> >
> > net is that app-hello-world should be release tad with tools not
> platforms
> > releases.
> >
> >
> >
> >
> >
> > On Thu, Aug 14, 2014 at 9:48 AM, Michal Mocny <mm...@chromium.org>
> wrote:
> >
> > > Does hello-world even need to be versioned at all, then?  Its just part
> > of
> > > the platform/cli release, and its assets are voted on as part of that?
> > >
> > >
> > > On Thu, Aug 14, 2014 at 9:43 AM, Andrew Grieve <ag...@chromium.org>
> > > wrote:
> > >
> > > > app-hello-world is quite a weird one now. There's two parts to it:
> > > > 1) default icons & splashscreens - copied into each platform
> > > > 2) default www/ - copied into each platform & into lazy_load'ed by
> CLI
> > > >
> > > > For 2) - I think we should stop lazy loading. Maybe just copy it into
> > the
> > > > CLI repo.
> > > >
> > > > For versioning though - I think the repo should be tagged / versioned
> > > > independently whenever it makes sense.
> > > >
> > > >
> > > > On Thu, Aug 14, 2014 at 9:16 AM, Ian Clelland <
> iclelland@chromium.org>
> > > > wrote:
> > > >
> > > > > Currently, mobile-spec needs to be tagged with platform versions,
> > since
> > > > it
> > > > > contains tests for those platforms, outside of the plugin tests
> (like
> > > the
> > > > > bridge and whitelist tests). As soon as we can move those out, then
> > > > > mobilespec becomes a generic test runner for Cordova, and we can
> just
> > > tag
> > > > > it independently of platforms.
> > > > >
> > > > >
> > > > > On Wed, Aug 13, 2014 at 6:12 PM, Steven Gill <
> stevengill97@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > New question
> > > > > >
> > > > > > How does tagging and versioning for cordova-app-hello-world and
> > > > > > cordova-mobile-spec look in this new world of independent
> releases?
> > > > > >
> > > > > > Currently:
> > > > > >
> > > > > > 1) They both get branched and tagged at the beginning of a
> cadence
> > > > > release.
> > > > > > 2) The hello world app is supposed to be manually copied to
> > platforms
> > > > if
> > > > > > changes exist.
> > > > > >
> > > > > > Suggestions:
> > > > > >
> > > > > > A) They both get tagged independently of platforms. Won't happen
> > > often
> > > > > > unless they are changing (the app rarely changes).
> > > > > >
> > > > > > B) They get tagged platform-version when doing a release. So
> mobile
> > > > spec
> > > > > > would have a tag android-3.6.0 when we are doing the 3.6.0
> release.
> > > > > >
> > > > > > I think we should stop branching for these two repos. Doesn't add
> > > much
> > > > > > value. The tag will take us back to the state when the platform
> was
> > > > > > released.
> > > > > >
> > > > > > Thoughts? Other suggestions?
> > > > > >
> > > > > >
> > > > > > On Fri, Aug 8, 2014 at 11:26 AM, Andrew Grieve <
> > agrieve@chromium.org
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > On Tue, Jul 29, 2014 at 5:00 PM, Steven Gill <
> > > stevengill97@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Started creating issues to keep track of all of these things.
> > > > > > > >
> > > > > > > > Master issue can be seen at
> > > > > > > https://issues.apache.org/jira/browse/CB-7221
> > > > > > > >
> > > > > > > > Setting CLI to version 4.0.0 sounds good to me. We can
> mention
> > in
> > > > the
> > > > > > > > release blog post how platforms are on their own schedule
> now.
> > > > > > > >
> > > > > > > > Option 3 for docs
> > > > > > > > - Docs get same version as CLI & get tagged alongside cli
> > > releases
> > > > > > > > - We can still annotate with "added in X.X.X, removed in
> X.X.X"
> > > > where
> > > > > > it
> > > > > > > > makes sense. (like the upgrade guides)
> > > > > > > > - Point docs.cordova.io to edge
> > > > > > > > - Dropdown will show tagged versions
> > > > > > > > Pros:
> > > > > > > > - Keeps a public history of older docs at a point in time.
> Easy
> > > to
> > > > > use
> > > > > > > for
> > > > > > > > people who don't want the latest
> > > > > > > > - Gives us flexibility in changing docs and not worrying
> about
> > > > older
> > > > > > > > versions.
> > > > > > > >
> > > > > > > > Thoughts?
> > > > > > > >
> > > > > > >
> > > > > > > Each new version of the docs has significant space requirements
> > > since
> > > > > we
> > > > > > > don't de-dupe images across versions or translations. Not the
> end
> > > of
> > > > > the
> > > > > > > world, but the repo is already > 1GB, so it is annoying.
> > > > > > >
> > > > > > > I don't think it's common that we delete docs, so maybe we
> could
> > > just
> > > > > > > create new versions when we do purges? Otherwise, the old
> > versions
> > > of
> > > > > > docs
> > > > > > > just have bugs and are strictly worse than the newest set, I
> > think.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > -Steve
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, Jul 28, 2014 at 8:26 AM, Michal Mocny <
> > > mmocny@chromium.org
> > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > On Mon, Jul 28, 2014 at 5:41 AM, Gorkem Ercan <
> > > > > > gorkem.ercan@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > This has been discussed long enough and even for those
> > > > downstream
> > > > > > > > > > distros and tools who will have to adjust, it is better
> to
> > > > > finalize
> > > > > > > it.
> > > > > > > > > >
> > > > > > > > > > Overall I like the plan, my major concern was with
> cadence
> > > > > > releaeses
> > > > > > > > > gone,
> > > > > > > > > > the lack of a
> > > > > > > > > > name/tag/version number for Cordova, and a description of
> > its
> > > > > > > contents.
> > > > > > > > > > Now, this is
> > > > > > > > > > addressed with CLI and package.json file.
> > > > > > > > > >
> > > > > > > > > > My +1 for this.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Fri, Jul 25, 2014 at 05:25:28PM -0400, Andrew Grieve
> > > wrote:
> > > > > > > > > > > Wanted to start a thread for everyone to share what
> > > concrete
> > > > > > > changes
> > > > > > > > > > they'd
> > > > > > > > > > > like to see happen before we start having platforms
> being
> > > > > > released
> > > > > > > in
> > > > > > > > > an
> > > > > > > > > > > unsynchronized fashion.
> > > > > > > > > > >
> > > > > > > > > > > I'll start :)
> > > > > > > > > > >
> > > > > > > > > > > cordova-js:
> > > > > > > > > > >  - cordova.version returns a value computed from the
> > > > cordova-js
> > > > > > git
> > > > > > > > > tag.
> > > > > > > > > > >    - Let's deprecate this field
> > > > > > > > > > >    - And create "cordova.platformVersion"
> > > > > > > > > > >    - And update our release process to have the version
> > set
> > > > > based
> > > > > > > on
> > > > > > > > > the
> > > > > > > > > > > platform's version rather than the tag within
> cordova-js.
> > > > > > > > > >
> > > > > > > > > > What will be the value for cordova.version during
> > deprecation
> > > > > > period?
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Cordova-docs:
> > > > > > > > > > >  - Most of the docs are not actually affected by
> platform
> > > > > > versions.
> > > > > > > > > > >  - Mainly though, it's the platform guides that are.
> > > > > > > > > > >  - Two options that I see:
> > > > > > > > > > >    - 1) Set default version to "edge" & always annotate
> > > with
> > > > > > "added
> > > > > > > > in
> > > > > > > > > > > X.X.X, removed in X.X.X"
> > > > > > > > > > >    - 2) Move guides to live in platform repos and link
> to
> > > > them
> > > > > > from
> > > > > > > > > docs.
> > > > > > > > > > >
> > > > > > > > > > > cordova-cli:
> > > > > > > > > > >   - Set version to 4.0.0 just to make it so that it
> > doesn't
> > > > map
> > > > > > to
> > > > > > > > any
> > > > > > > > > > > existing platform versions
> > > > > > > > > >
> > > > > > > > > > Not sure if this matters. Platforms will catch up to
> 4.0.0
> > > soon
> > > > > > > enough.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > CLI version is currently "3.5.0-0.2.7-dev".  We need to
> > change
> > > it
> > > > > to
> > > > > > > > > something thats valid semver, and preferably somewhat
> > > compatible
> > > > > with
> > > > > > > the
> > > > > > > > > previous versions.  Choices I think are:
> > > > > > > > > - 3.6.0
> > > > > > > > > - 4.0.0
> > > > > > > > > - A Complete reset
> > > > > > > > >
> > > > > > > > > I'm also in favour of 4.0.0 given those options.
> > > > > > > > >
> > > > > > > > > I am mildly concerned that with the looming 4.0 releases of
> > > > > > platforms,
> > > > > > > > > users will think this is a cad-ver update and not
> appreciate
> > > the
> > > > > > change
> > > > > > > > of
> > > > > > > > > strategy, but partially think that may be a good thing too
> > > (slow
> > > > > > > > > comfortable transition).
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Release Process:
> > > > > > > > > > >   - Tag cordova-js for each platform release with
> > > > > > > "PLATFORM-VERSION"
> > > > > > > > > > >   - Rewrite
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
> > > > > > > > > > > as "platforms-release-process"
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Carlos Santana
> > <cs...@gmail.com>
> >
>



-- 
Carlos Santana
<cs...@gmail.com>

Re: What's Stopping us From Independent Platform Releases

[Brian LeRoux <b...@brian.io>]

rather than bundle app-hello-world I'd rather we *extracted*
cordova-project-create from cordova-lib into its own module so thing that
create cordova projects only have one way of doing it



On Thu, Aug 14, 2014 at 7:58 AM, Carlos Santana <cs...@gmail.com>
wrote:

> Each platform should carry their default contents including set of icons
> and screens for none CLI workflow, the platform can keep taking them from
> app-hello-world as part of it's independent platform release.
>
> For app-hello-world it should be tag and release with the tools (CLI
> release) as it's use as the default template for "create"
>
> Now that I think CLI and config.xml supports icons and screens, the default
> app created by CLI should include the "res/" icons and screens, including a
> config.xml configured with proper values pointing to the images.
> This will be easier to end user to figure out on disk what files it needs
> to be modified in the "res/" directory on CLI project.
>
> This can also be optimized that "res/" contents get populated as the
> "cordova platform add" gets executed so user only gets in "res/" and
> "config.xml" only the platforms added.
>
> I was looking into this recently as I'm trying to create a new universal
> www template for IBM Worklight to be use by cordova CLI, but I got brain
> stop on how do I create a git repo that includes all my default icons and
> screens that user will replace, but don't want to pollute their cordova
> project with images from a platform their not dealing with yet, and how to
> add those icons and screens when they do an "platform add" for a new
> platform.
>
> Maybe this deserves a new thread.
>
> net is that app-hello-world should be release tad with tools not platforms
> releases.
>
>
>
>
>
> On Thu, Aug 14, 2014 at 9:48 AM, Michal Mocny <mm...@chromium.org> wrote:
>
> > Does hello-world even need to be versioned at all, then?  Its just part
> of
> > the platform/cli release, and its assets are voted on as part of that?
> >
> >
> > On Thu, Aug 14, 2014 at 9:43 AM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> >
> > > app-hello-world is quite a weird one now. There's two parts to it:
> > > 1) default icons & splashscreens - copied into each platform
> > > 2) default www/ - copied into each platform & into lazy_load'ed by CLI
> > >
> > > For 2) - I think we should stop lazy loading. Maybe just copy it into
> the
> > > CLI repo.
> > >
> > > For versioning though - I think the repo should be tagged / versioned
> > > independently whenever it makes sense.
> > >
> > >
> > > On Thu, Aug 14, 2014 at 9:16 AM, Ian Clelland <ic...@chromium.org>
> > > wrote:
> > >
> > > > Currently, mobile-spec needs to be tagged with platform versions,
> since
> > > it
> > > > contains tests for those platforms, outside of the plugin tests (like
> > the
> > > > bridge and whitelist tests). As soon as we can move those out, then
> > > > mobilespec becomes a generic test runner for Cordova, and we can just
> > tag
> > > > it independently of platforms.
> > > >
> > > >
> > > > On Wed, Aug 13, 2014 at 6:12 PM, Steven Gill <stevengill97@gmail.com
> >
> > > > wrote:
> > > >
> > > > > New question
> > > > >
> > > > > How does tagging and versioning for cordova-app-hello-world and
> > > > > cordova-mobile-spec look in this new world of independent releases?
> > > > >
> > > > > Currently:
> > > > >
> > > > > 1) They both get branched and tagged at the beginning of a cadence
> > > > release.
> > > > > 2) The hello world app is supposed to be manually copied to
> platforms
> > > if
> > > > > changes exist.
> > > > >
> > > > > Suggestions:
> > > > >
> > > > > A) They both get tagged independently of platforms. Won't happen
> > often
> > > > > unless they are changing (the app rarely changes).
> > > > >
> > > > > B) They get tagged platform-version when doing a release. So mobile
> > > spec
> > > > > would have a tag android-3.6.0 when we are doing the 3.6.0 release.
> > > > >
> > > > > I think we should stop branching for these two repos. Doesn't add
> > much
> > > > > value. The tag will take us back to the state when the platform was
> > > > > released.
> > > > >
> > > > > Thoughts? Other suggestions?
> > > > >
> > > > >
> > > > > On Fri, Aug 8, 2014 at 11:26 AM, Andrew Grieve <
> agrieve@chromium.org
> > >
> > > > > wrote:
> > > > >
> > > > > > On Tue, Jul 29, 2014 at 5:00 PM, Steven Gill <
> > stevengill97@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Started creating issues to keep track of all of these things.
> > > > > > >
> > > > > > > Master issue can be seen at
> > > > > > https://issues.apache.org/jira/browse/CB-7221
> > > > > > >
> > > > > > > Setting CLI to version 4.0.0 sounds good to me. We can mention
> in
> > > the
> > > > > > > release blog post how platforms are on their own schedule now.
> > > > > > >
> > > > > > > Option 3 for docs
> > > > > > > - Docs get same version as CLI & get tagged alongside cli
> > releases
> > > > > > > - We can still annotate with "added in X.X.X, removed in X.X.X"
> > > where
> > > > > it
> > > > > > > makes sense. (like the upgrade guides)
> > > > > > > - Point docs.cordova.io to edge
> > > > > > > - Dropdown will show tagged versions
> > > > > > > Pros:
> > > > > > > - Keeps a public history of older docs at a point in time. Easy
> > to
> > > > use
> > > > > > for
> > > > > > > people who don't want the latest
> > > > > > > - Gives us flexibility in changing docs and not worrying about
> > > older
> > > > > > > versions.
> > > > > > >
> > > > > > > Thoughts?
> > > > > > >
> > > > > >
> > > > > > Each new version of the docs has significant space requirements
> > since
> > > > we
> > > > > > don't de-dupe images across versions or translations. Not the end
> > of
> > > > the
> > > > > > world, but the repo is already > 1GB, so it is annoying.
> > > > > >
> > > > > > I don't think it's common that we delete docs, so maybe we could
> > just
> > > > > > create new versions when we do purges? Otherwise, the old
> versions
> > of
> > > > > docs
> > > > > > just have bugs and are strictly worse than the newest set, I
> think.
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > -Steve
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Jul 28, 2014 at 8:26 AM, Michal Mocny <
> > mmocny@chromium.org
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > On Mon, Jul 28, 2014 at 5:41 AM, Gorkem Ercan <
> > > > > gorkem.ercan@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > > This has been discussed long enough and even for those
> > > downstream
> > > > > > > > > distros and tools who will have to adjust, it is better to
> > > > finalize
> > > > > > it.
> > > > > > > > >
> > > > > > > > > Overall I like the plan, my major concern was with cadence
> > > > > releaeses
> > > > > > > > gone,
> > > > > > > > > the lack of a
> > > > > > > > > name/tag/version number for Cordova, and a description of
> its
> > > > > > contents.
> > > > > > > > > Now, this is
> > > > > > > > > addressed with CLI and package.json file.
> > > > > > > > >
> > > > > > > > > My +1 for this.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Jul 25, 2014 at 05:25:28PM -0400, Andrew Grieve
> > wrote:
> > > > > > > > > > Wanted to start a thread for everyone to share what
> > concrete
> > > > > > changes
> > > > > > > > > they'd
> > > > > > > > > > like to see happen before we start having platforms being
> > > > > released
> > > > > > in
> > > > > > > > an
> > > > > > > > > > unsynchronized fashion.
> > > > > > > > > >
> > > > > > > > > > I'll start :)
> > > > > > > > > >
> > > > > > > > > > cordova-js:
> > > > > > > > > >  - cordova.version returns a value computed from the
> > > cordova-js
> > > > > git
> > > > > > > > tag.
> > > > > > > > > >    - Let's deprecate this field
> > > > > > > > > >    - And create "cordova.platformVersion"
> > > > > > > > > >    - And update our release process to have the version
> set
> > > > based
> > > > > > on
> > > > > > > > the
> > > > > > > > > > platform's version rather than the tag within cordova-js.
> > > > > > > > >
> > > > > > > > > What will be the value for cordova.version during
> deprecation
> > > > > period?
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Cordova-docs:
> > > > > > > > > >  - Most of the docs are not actually affected by platform
> > > > > versions.
> > > > > > > > > >  - Mainly though, it's the platform guides that are.
> > > > > > > > > >  - Two options that I see:
> > > > > > > > > >    - 1) Set default version to "edge" & always annotate
> > with
> > > > > "added
> > > > > > > in
> > > > > > > > > > X.X.X, removed in X.X.X"
> > > > > > > > > >    - 2) Move guides to live in platform repos and link to
> > > them
> > > > > from
> > > > > > > > docs.
> > > > > > > > > >
> > > > > > > > > > cordova-cli:
> > > > > > > > > >   - Set version to 4.0.0 just to make it so that it
> doesn't
> > > map
> > > > > to
> > > > > > > any
> > > > > > > > > > existing platform versions
> > > > > > > > >
> > > > > > > > > Not sure if this matters. Platforms will catch up to 4.0.0
> > soon
> > > > > > enough.
> > > > > > > > >
> > > > > > > >
> > > > > > > > CLI version is currently "3.5.0-0.2.7-dev".  We need to
> change
> > it
> > > > to
> > > > > > > > something thats valid semver, and preferably somewhat
> > compatible
> > > > with
> > > > > > the
> > > > > > > > previous versions.  Choices I think are:
> > > > > > > > - 3.6.0
> > > > > > > > - 4.0.0
> > > > > > > > - A Complete reset
> > > > > > > >
> > > > > > > > I'm also in favour of 4.0.0 given those options.
> > > > > > > >
> > > > > > > > I am mildly concerned that with the looming 4.0 releases of
> > > > > platforms,
> > > > > > > > users will think this is a cad-ver update and not appreciate
> > the
> > > > > change
> > > > > > > of
> > > > > > > > strategy, but partially think that may be a good thing too
> > (slow
> > > > > > > > comfortable transition).
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Release Process:
> > > > > > > > > >   - Tag cordova-js for each platform release with
> > > > > > "PLATFORM-VERSION"
> > > > > > > > > >   - Rewrite
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
> > > > > > > > > > as "platforms-release-process"
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
>
> --
> Carlos Santana
> <cs...@gmail.com>
>

Re: What's Stopping us From Independent Platform Releases

[Carlos Santana <cs...@gmail.com>]

Each platform should carry their default contents including set of icons
and screens for none CLI workflow, the platform can keep taking them from
app-hello-world as part of it's independent platform release.

For app-hello-world it should be tag and release with the tools (CLI
release) as it's use as the default template for "create"

Now that I think CLI and config.xml supports icons and screens, the default
app created by CLI should include the "res/" icons and screens, including a
config.xml configured with proper values pointing to the images.
This will be easier to end user to figure out on disk what files it needs
to be modified in the "res/" directory on CLI project.

This can also be optimized that "res/" contents get populated as the
"cordova platform add" gets executed so user only gets in "res/" and
"config.xml" only the platforms added.

I was looking into this recently as I'm trying to create a new universal
www template for IBM Worklight to be use by cordova CLI, but I got brain
stop on how do I create a git repo that includes all my default icons and
screens that user will replace, but don't want to pollute their cordova
project with images from a platform their not dealing with yet, and how to
add those icons and screens when they do an "platform add" for a new
platform.

Maybe this deserves a new thread.

net is that app-hello-world should be release tad with tools not platforms
releases.





On Thu, Aug 14, 2014 at 9:48 AM, Michal Mocny <mm...@chromium.org> wrote:

> Does hello-world even need to be versioned at all, then?  Its just part of
> the platform/cli release, and its assets are voted on as part of that?
>
>
> On Thu, Aug 14, 2014 at 9:43 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > app-hello-world is quite a weird one now. There's two parts to it:
> > 1) default icons & splashscreens - copied into each platform
> > 2) default www/ - copied into each platform & into lazy_load'ed by CLI
> >
> > For 2) - I think we should stop lazy loading. Maybe just copy it into the
> > CLI repo.
> >
> > For versioning though - I think the repo should be tagged / versioned
> > independently whenever it makes sense.
> >
> >
> > On Thu, Aug 14, 2014 at 9:16 AM, Ian Clelland <ic...@chromium.org>
> > wrote:
> >
> > > Currently, mobile-spec needs to be tagged with platform versions, since
> > it
> > > contains tests for those platforms, outside of the plugin tests (like
> the
> > > bridge and whitelist tests). As soon as we can move those out, then
> > > mobilespec becomes a generic test runner for Cordova, and we can just
> tag
> > > it independently of platforms.
> > >
> > >
> > > On Wed, Aug 13, 2014 at 6:12 PM, Steven Gill <st...@gmail.com>
> > > wrote:
> > >
> > > > New question
> > > >
> > > > How does tagging and versioning for cordova-app-hello-world and
> > > > cordova-mobile-spec look in this new world of independent releases?
> > > >
> > > > Currently:
> > > >
> > > > 1) They both get branched and tagged at the beginning of a cadence
> > > release.
> > > > 2) The hello world app is supposed to be manually copied to platforms
> > if
> > > > changes exist.
> > > >
> > > > Suggestions:
> > > >
> > > > A) They both get tagged independently of platforms. Won't happen
> often
> > > > unless they are changing (the app rarely changes).
> > > >
> > > > B) They get tagged platform-version when doing a release. So mobile
> > spec
> > > > would have a tag android-3.6.0 when we are doing the 3.6.0 release.
> > > >
> > > > I think we should stop branching for these two repos. Doesn't add
> much
> > > > value. The tag will take us back to the state when the platform was
> > > > released.
> > > >
> > > > Thoughts? Other suggestions?
> > > >
> > > >
> > > > On Fri, Aug 8, 2014 at 11:26 AM, Andrew Grieve <agrieve@chromium.org
> >
> > > > wrote:
> > > >
> > > > > On Tue, Jul 29, 2014 at 5:00 PM, Steven Gill <
> stevengill97@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > Started creating issues to keep track of all of these things.
> > > > > >
> > > > > > Master issue can be seen at
> > > > > https://issues.apache.org/jira/browse/CB-7221
> > > > > >
> > > > > > Setting CLI to version 4.0.0 sounds good to me. We can mention in
> > the
> > > > > > release blog post how platforms are on their own schedule now.
> > > > > >
> > > > > > Option 3 for docs
> > > > > > - Docs get same version as CLI & get tagged alongside cli
> releases
> > > > > > - We can still annotate with "added in X.X.X, removed in X.X.X"
> > where
> > > > it
> > > > > > makes sense. (like the upgrade guides)
> > > > > > - Point docs.cordova.io to edge
> > > > > > - Dropdown will show tagged versions
> > > > > > Pros:
> > > > > > - Keeps a public history of older docs at a point in time. Easy
> to
> > > use
> > > > > for
> > > > > > people who don't want the latest
> > > > > > - Gives us flexibility in changing docs and not worrying about
> > older
> > > > > > versions.
> > > > > >
> > > > > > Thoughts?
> > > > > >
> > > > >
> > > > > Each new version of the docs has significant space requirements
> since
> > > we
> > > > > don't de-dupe images across versions or translations. Not the end
> of
> > > the
> > > > > world, but the repo is already > 1GB, so it is annoying.
> > > > >
> > > > > I don't think it's common that we delete docs, so maybe we could
> just
> > > > > create new versions when we do purges? Otherwise, the old versions
> of
> > > > docs
> > > > > just have bugs and are strictly worse than the newest set, I think.
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > -Steve
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, Jul 28, 2014 at 8:26 AM, Michal Mocny <
> mmocny@chromium.org
> > >
> > > > > wrote:
> > > > > >
> > > > > > > On Mon, Jul 28, 2014 at 5:41 AM, Gorkem Ercan <
> > > > gorkem.ercan@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > This has been discussed long enough and even for those
> > downstream
> > > > > > > > distros and tools who will have to adjust, it is better to
> > > finalize
> > > > > it.
> > > > > > > >
> > > > > > > > Overall I like the plan, my major concern was with cadence
> > > > releaeses
> > > > > > > gone,
> > > > > > > > the lack of a
> > > > > > > > name/tag/version number for Cordova, and a description of its
> > > > > contents.
> > > > > > > > Now, this is
> > > > > > > > addressed with CLI and package.json file.
> > > > > > > >
> > > > > > > > My +1 for this.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Jul 25, 2014 at 05:25:28PM -0400, Andrew Grieve
> wrote:
> > > > > > > > > Wanted to start a thread for everyone to share what
> concrete
> > > > > changes
> > > > > > > > they'd
> > > > > > > > > like to see happen before we start having platforms being
> > > > released
> > > > > in
> > > > > > > an
> > > > > > > > > unsynchronized fashion.
> > > > > > > > >
> > > > > > > > > I'll start :)
> > > > > > > > >
> > > > > > > > > cordova-js:
> > > > > > > > >  - cordova.version returns a value computed from the
> > cordova-js
> > > > git
> > > > > > > tag.
> > > > > > > > >    - Let's deprecate this field
> > > > > > > > >    - And create "cordova.platformVersion"
> > > > > > > > >    - And update our release process to have the version set
> > > based
> > > > > on
> > > > > > > the
> > > > > > > > > platform's version rather than the tag within cordova-js.
> > > > > > > >
> > > > > > > > What will be the value for cordova.version during deprecation
> > > > period?
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Cordova-docs:
> > > > > > > > >  - Most of the docs are not actually affected by platform
> > > > versions.
> > > > > > > > >  - Mainly though, it's the platform guides that are.
> > > > > > > > >  - Two options that I see:
> > > > > > > > >    - 1) Set default version to "edge" & always annotate
> with
> > > > "added
> > > > > > in
> > > > > > > > > X.X.X, removed in X.X.X"
> > > > > > > > >    - 2) Move guides to live in platform repos and link to
> > them
> > > > from
> > > > > > > docs.
> > > > > > > > >
> > > > > > > > > cordova-cli:
> > > > > > > > >   - Set version to 4.0.0 just to make it so that it doesn't
> > map
> > > > to
> > > > > > any
> > > > > > > > > existing platform versions
> > > > > > > >
> > > > > > > > Not sure if this matters. Platforms will catch up to 4.0.0
> soon
> > > > > enough.
> > > > > > > >
> > > > > > >
> > > > > > > CLI version is currently "3.5.0-0.2.7-dev".  We need to change
> it
> > > to
> > > > > > > something thats valid semver, and preferably somewhat
> compatible
> > > with
> > > > > the
> > > > > > > previous versions.  Choices I think are:
> > > > > > > - 3.6.0
> > > > > > > - 4.0.0
> > > > > > > - A Complete reset
> > > > > > >
> > > > > > > I'm also in favour of 4.0.0 given those options.
> > > > > > >
> > > > > > > I am mildly concerned that with the looming 4.0 releases of
> > > > platforms,
> > > > > > > users will think this is a cad-ver update and not appreciate
> the
> > > > change
> > > > > > of
> > > > > > > strategy, but partially think that may be a good thing too
> (slow
> > > > > > > comfortable transition).
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Release Process:
> > > > > > > > >   - Tag cordova-js for each platform release with
> > > > > "PLATFORM-VERSION"
> > > > > > > > >   - Rewrite
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
> > > > > > > > > as "platforms-release-process"
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>



-- 
Carlos Santana
<cs...@gmail.com>

Re: What's Stopping us From Independent Platform Releases

[Michal Mocny <mm...@chromium.org>]

Does hello-world even need to be versioned at all, then?  Its just part of
the platform/cli release, and its assets are voted on as part of that?


On Thu, Aug 14, 2014 at 9:43 AM, Andrew Grieve <ag...@chromium.org> wrote:

> app-hello-world is quite a weird one now. There's two parts to it:
> 1) default icons & splashscreens - copied into each platform
> 2) default www/ - copied into each platform & into lazy_load'ed by CLI
>
> For 2) - I think we should stop lazy loading. Maybe just copy it into the
> CLI repo.
>
> For versioning though - I think the repo should be tagged / versioned
> independently whenever it makes sense.
>
>
> On Thu, Aug 14, 2014 at 9:16 AM, Ian Clelland <ic...@chromium.org>
> wrote:
>
> > Currently, mobile-spec needs to be tagged with platform versions, since
> it
> > contains tests for those platforms, outside of the plugin tests (like the
> > bridge and whitelist tests). As soon as we can move those out, then
> > mobilespec becomes a generic test runner for Cordova, and we can just tag
> > it independently of platforms.
> >
> >
> > On Wed, Aug 13, 2014 at 6:12 PM, Steven Gill <st...@gmail.com>
> > wrote:
> >
> > > New question
> > >
> > > How does tagging and versioning for cordova-app-hello-world and
> > > cordova-mobile-spec look in this new world of independent releases?
> > >
> > > Currently:
> > >
> > > 1) They both get branched and tagged at the beginning of a cadence
> > release.
> > > 2) The hello world app is supposed to be manually copied to platforms
> if
> > > changes exist.
> > >
> > > Suggestions:
> > >
> > > A) They both get tagged independently of platforms. Won't happen often
> > > unless they are changing (the app rarely changes).
> > >
> > > B) They get tagged platform-version when doing a release. So mobile
> spec
> > > would have a tag android-3.6.0 when we are doing the 3.6.0 release.
> > >
> > > I think we should stop branching for these two repos. Doesn't add much
> > > value. The tag will take us back to the state when the platform was
> > > released.
> > >
> > > Thoughts? Other suggestions?
> > >
> > >
> > > On Fri, Aug 8, 2014 at 11:26 AM, Andrew Grieve <ag...@chromium.org>
> > > wrote:
> > >
> > > > On Tue, Jul 29, 2014 at 5:00 PM, Steven Gill <stevengill97@gmail.com
> >
> > > > wrote:
> > > >
> > > > > Started creating issues to keep track of all of these things.
> > > > >
> > > > > Master issue can be seen at
> > > > https://issues.apache.org/jira/browse/CB-7221
> > > > >
> > > > > Setting CLI to version 4.0.0 sounds good to me. We can mention in
> the
> > > > > release blog post how platforms are on their own schedule now.
> > > > >
> > > > > Option 3 for docs
> > > > > - Docs get same version as CLI & get tagged alongside cli releases
> > > > > - We can still annotate with "added in X.X.X, removed in X.X.X"
> where
> > > it
> > > > > makes sense. (like the upgrade guides)
> > > > > - Point docs.cordova.io to edge
> > > > > - Dropdown will show tagged versions
> > > > > Pros:
> > > > > - Keeps a public history of older docs at a point in time. Easy to
> > use
> > > > for
> > > > > people who don't want the latest
> > > > > - Gives us flexibility in changing docs and not worrying about
> older
> > > > > versions.
> > > > >
> > > > > Thoughts?
> > > > >
> > > >
> > > > Each new version of the docs has significant space requirements since
> > we
> > > > don't de-dupe images across versions or translations. Not the end of
> > the
> > > > world, but the repo is already > 1GB, so it is annoying.
> > > >
> > > > I don't think it's common that we delete docs, so maybe we could just
> > > > create new versions when we do purges? Otherwise, the old versions of
> > > docs
> > > > just have bugs and are strictly worse than the newest set, I think.
> > > >
> > > >
> > > >
> > > > >
> > > > > -Steve
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Jul 28, 2014 at 8:26 AM, Michal Mocny <mmocny@chromium.org
> >
> > > > wrote:
> > > > >
> > > > > > On Mon, Jul 28, 2014 at 5:41 AM, Gorkem Ercan <
> > > gorkem.ercan@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > This has been discussed long enough and even for those
> downstream
> > > > > > > distros and tools who will have to adjust, it is better to
> > finalize
> > > > it.
> > > > > > >
> > > > > > > Overall I like the plan, my major concern was with cadence
> > > releaeses
> > > > > > gone,
> > > > > > > the lack of a
> > > > > > > name/tag/version number for Cordova, and a description of its
> > > > contents.
> > > > > > > Now, this is
> > > > > > > addressed with CLI and package.json file.
> > > > > > >
> > > > > > > My +1 for this.
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Jul 25, 2014 at 05:25:28PM -0400, Andrew Grieve wrote:
> > > > > > > > Wanted to start a thread for everyone to share what concrete
> > > > changes
> > > > > > > they'd
> > > > > > > > like to see happen before we start having platforms being
> > > released
> > > > in
> > > > > > an
> > > > > > > > unsynchronized fashion.
> > > > > > > >
> > > > > > > > I'll start :)
> > > > > > > >
> > > > > > > > cordova-js:
> > > > > > > >  - cordova.version returns a value computed from the
> cordova-js
> > > git
> > > > > > tag.
> > > > > > > >    - Let's deprecate this field
> > > > > > > >    - And create "cordova.platformVersion"
> > > > > > > >    - And update our release process to have the version set
> > based
> > > > on
> > > > > > the
> > > > > > > > platform's version rather than the tag within cordova-js.
> > > > > > >
> > > > > > > What will be the value for cordova.version during deprecation
> > > period?
> > > > > > >
> > > > > > > >
> > > > > > > > Cordova-docs:
> > > > > > > >  - Most of the docs are not actually affected by platform
> > > versions.
> > > > > > > >  - Mainly though, it's the platform guides that are.
> > > > > > > >  - Two options that I see:
> > > > > > > >    - 1) Set default version to "edge" & always annotate with
> > > "added
> > > > > in
> > > > > > > > X.X.X, removed in X.X.X"
> > > > > > > >    - 2) Move guides to live in platform repos and link to
> them
> > > from
> > > > > > docs.
> > > > > > > >
> > > > > > > > cordova-cli:
> > > > > > > >   - Set version to 4.0.0 just to make it so that it doesn't
> map
> > > to
> > > > > any
> > > > > > > > existing platform versions
> > > > > > >
> > > > > > > Not sure if this matters. Platforms will catch up to 4.0.0 soon
> > > > enough.
> > > > > > >
> > > > > >
> > > > > > CLI version is currently "3.5.0-0.2.7-dev".  We need to change it
> > to
> > > > > > something thats valid semver, and preferably somewhat compatible
> > with
> > > > the
> > > > > > previous versions.  Choices I think are:
> > > > > > - 3.6.0
> > > > > > - 4.0.0
> > > > > > - A Complete reset
> > > > > >
> > > > > > I'm also in favour of 4.0.0 given those options.
> > > > > >
> > > > > > I am mildly concerned that with the looming 4.0 releases of
> > > platforms,
> > > > > > users will think this is a cad-ver update and not appreciate the
> > > change
> > > > > of
> > > > > > strategy, but partially think that may be a good thing too (slow
> > > > > > comfortable transition).
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Release Process:
> > > > > > > >   - Tag cordova-js for each platform release with
> > > > "PLATFORM-VERSION"
> > > > > > > >   - Rewrite
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
> > > > > > > > as "platforms-release-process"
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: What's Stopping us From Independent Platform Releases

[Andrew Grieve <ag...@chromium.org>]

app-hello-world is quite a weird one now. There's two parts to it:
1) default icons & splashscreens - copied into each platform
2) default www/ - copied into each platform & into lazy_load'ed by CLI

For 2) - I think we should stop lazy loading. Maybe just copy it into the
CLI repo.

For versioning though - I think the repo should be tagged / versioned
independently whenever it makes sense.


On Thu, Aug 14, 2014 at 9:16 AM, Ian Clelland <ic...@chromium.org>
wrote:

> Currently, mobile-spec needs to be tagged with platform versions, since it
> contains tests for those platforms, outside of the plugin tests (like the
> bridge and whitelist tests). As soon as we can move those out, then
> mobilespec becomes a generic test runner for Cordova, and we can just tag
> it independently of platforms.
>
>
> On Wed, Aug 13, 2014 at 6:12 PM, Steven Gill <st...@gmail.com>
> wrote:
>
> > New question
> >
> > How does tagging and versioning for cordova-app-hello-world and
> > cordova-mobile-spec look in this new world of independent releases?
> >
> > Currently:
> >
> > 1) They both get branched and tagged at the beginning of a cadence
> release.
> > 2) The hello world app is supposed to be manually copied to platforms if
> > changes exist.
> >
> > Suggestions:
> >
> > A) They both get tagged independently of platforms. Won't happen often
> > unless they are changing (the app rarely changes).
> >
> > B) They get tagged platform-version when doing a release. So mobile spec
> > would have a tag android-3.6.0 when we are doing the 3.6.0 release.
> >
> > I think we should stop branching for these two repos. Doesn't add much
> > value. The tag will take us back to the state when the platform was
> > released.
> >
> > Thoughts? Other suggestions?
> >
> >
> > On Fri, Aug 8, 2014 at 11:26 AM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> >
> > > On Tue, Jul 29, 2014 at 5:00 PM, Steven Gill <st...@gmail.com>
> > > wrote:
> > >
> > > > Started creating issues to keep track of all of these things.
> > > >
> > > > Master issue can be seen at
> > > https://issues.apache.org/jira/browse/CB-7221
> > > >
> > > > Setting CLI to version 4.0.0 sounds good to me. We can mention in the
> > > > release blog post how platforms are on their own schedule now.
> > > >
> > > > Option 3 for docs
> > > > - Docs get same version as CLI & get tagged alongside cli releases
> > > > - We can still annotate with "added in X.X.X, removed in X.X.X" where
> > it
> > > > makes sense. (like the upgrade guides)
> > > > - Point docs.cordova.io to edge
> > > > - Dropdown will show tagged versions
> > > > Pros:
> > > > - Keeps a public history of older docs at a point in time. Easy to
> use
> > > for
> > > > people who don't want the latest
> > > > - Gives us flexibility in changing docs and not worrying about older
> > > > versions.
> > > >
> > > > Thoughts?
> > > >
> > >
> > > Each new version of the docs has significant space requirements since
> we
> > > don't de-dupe images across versions or translations. Not the end of
> the
> > > world, but the repo is already > 1GB, so it is annoying.
> > >
> > > I don't think it's common that we delete docs, so maybe we could just
> > > create new versions when we do purges? Otherwise, the old versions of
> > docs
> > > just have bugs and are strictly worse than the newest set, I think.
> > >
> > >
> > >
> > > >
> > > > -Steve
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Jul 28, 2014 at 8:26 AM, Michal Mocny <mm...@chromium.org>
> > > wrote:
> > > >
> > > > > On Mon, Jul 28, 2014 at 5:41 AM, Gorkem Ercan <
> > gorkem.ercan@gmail.com>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > This has been discussed long enough and even for those downstream
> > > > > > distros and tools who will have to adjust, it is better to
> finalize
> > > it.
> > > > > >
> > > > > > Overall I like the plan, my major concern was with cadence
> > releaeses
> > > > > gone,
> > > > > > the lack of a
> > > > > > name/tag/version number for Cordova, and a description of its
> > > contents.
> > > > > > Now, this is
> > > > > > addressed with CLI and package.json file.
> > > > > >
> > > > > > My +1 for this.
> > > > > >
> > > > > >
> > > > > > On Fri, Jul 25, 2014 at 05:25:28PM -0400, Andrew Grieve wrote:
> > > > > > > Wanted to start a thread for everyone to share what concrete
> > > changes
> > > > > > they'd
> > > > > > > like to see happen before we start having platforms being
> > released
> > > in
> > > > > an
> > > > > > > unsynchronized fashion.
> > > > > > >
> > > > > > > I'll start :)
> > > > > > >
> > > > > > > cordova-js:
> > > > > > >  - cordova.version returns a value computed from the cordova-js
> > git
> > > > > tag.
> > > > > > >    - Let's deprecate this field
> > > > > > >    - And create "cordova.platformVersion"
> > > > > > >    - And update our release process to have the version set
> based
> > > on
> > > > > the
> > > > > > > platform's version rather than the tag within cordova-js.
> > > > > >
> > > > > > What will be the value for cordova.version during deprecation
> > period?
> > > > > >
> > > > > > >
> > > > > > > Cordova-docs:
> > > > > > >  - Most of the docs are not actually affected by platform
> > versions.
> > > > > > >  - Mainly though, it's the platform guides that are.
> > > > > > >  - Two options that I see:
> > > > > > >    - 1) Set default version to "edge" & always annotate with
> > "added
> > > > in
> > > > > > > X.X.X, removed in X.X.X"
> > > > > > >    - 2) Move guides to live in platform repos and link to them
> > from
> > > > > docs.
> > > > > > >
> > > > > > > cordova-cli:
> > > > > > >   - Set version to 4.0.0 just to make it so that it doesn't map
> > to
> > > > any
> > > > > > > existing platform versions
> > > > > >
> > > > > > Not sure if this matters. Platforms will catch up to 4.0.0 soon
> > > enough.
> > > > > >
> > > > >
> > > > > CLI version is currently "3.5.0-0.2.7-dev".  We need to change it
> to
> > > > > something thats valid semver, and preferably somewhat compatible
> with
> > > the
> > > > > previous versions.  Choices I think are:
> > > > > - 3.6.0
> > > > > - 4.0.0
> > > > > - A Complete reset
> > > > >
> > > > > I'm also in favour of 4.0.0 given those options.
> > > > >
> > > > > I am mildly concerned that with the looming 4.0 releases of
> > platforms,
> > > > > users will think this is a cad-ver update and not appreciate the
> > change
> > > > of
> > > > > strategy, but partially think that may be a good thing too (slow
> > > > > comfortable transition).
> > > > >
> > > > >
> > > > > >
> > > > > > >
> > > > > > > Release Process:
> > > > > > >   - Tag cordova-js for each platform release with
> > > "PLATFORM-VERSION"
> > > > > > >   - Rewrite
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
> > > > > > > as "platforms-release-process"
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: What's Stopping us From Independent Platform Releases

[Ian Clelland <ic...@chromium.org>]

Currently, mobile-spec needs to be tagged with platform versions, since it
contains tests for those platforms, outside of the plugin tests (like the
bridge and whitelist tests). As soon as we can move those out, then
mobilespec becomes a generic test runner for Cordova, and we can just tag
it independently of platforms.


On Wed, Aug 13, 2014 at 6:12 PM, Steven Gill <st...@gmail.com> wrote:

> New question
>
> How does tagging and versioning for cordova-app-hello-world and
> cordova-mobile-spec look in this new world of independent releases?
>
> Currently:
>
> 1) They both get branched and tagged at the beginning of a cadence release.
> 2) The hello world app is supposed to be manually copied to platforms if
> changes exist.
>
> Suggestions:
>
> A) They both get tagged independently of platforms. Won't happen often
> unless they are changing (the app rarely changes).
>
> B) They get tagged platform-version when doing a release. So mobile spec
> would have a tag android-3.6.0 when we are doing the 3.6.0 release.
>
> I think we should stop branching for these two repos. Doesn't add much
> value. The tag will take us back to the state when the platform was
> released.
>
> Thoughts? Other suggestions?
>
>
> On Fri, Aug 8, 2014 at 11:26 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > On Tue, Jul 29, 2014 at 5:00 PM, Steven Gill <st...@gmail.com>
> > wrote:
> >
> > > Started creating issues to keep track of all of these things.
> > >
> > > Master issue can be seen at
> > https://issues.apache.org/jira/browse/CB-7221
> > >
> > > Setting CLI to version 4.0.0 sounds good to me. We can mention in the
> > > release blog post how platforms are on their own schedule now.
> > >
> > > Option 3 for docs
> > > - Docs get same version as CLI & get tagged alongside cli releases
> > > - We can still annotate with "added in X.X.X, removed in X.X.X" where
> it
> > > makes sense. (like the upgrade guides)
> > > - Point docs.cordova.io to edge
> > > - Dropdown will show tagged versions
> > > Pros:
> > > - Keeps a public history of older docs at a point in time. Easy to use
> > for
> > > people who don't want the latest
> > > - Gives us flexibility in changing docs and not worrying about older
> > > versions.
> > >
> > > Thoughts?
> > >
> >
> > Each new version of the docs has significant space requirements since we
> > don't de-dupe images across versions or translations. Not the end of the
> > world, but the repo is already > 1GB, so it is annoying.
> >
> > I don't think it's common that we delete docs, so maybe we could just
> > create new versions when we do purges? Otherwise, the old versions of
> docs
> > just have bugs and are strictly worse than the newest set, I think.
> >
> >
> >
> > >
> > > -Steve
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Jul 28, 2014 at 8:26 AM, Michal Mocny <mm...@chromium.org>
> > wrote:
> > >
> > > > On Mon, Jul 28, 2014 at 5:41 AM, Gorkem Ercan <
> gorkem.ercan@gmail.com>
> > > > wrote:
> > > >
> > > > >
> > > > > This has been discussed long enough and even for those downstream
> > > > > distros and tools who will have to adjust, it is better to finalize
> > it.
> > > > >
> > > > > Overall I like the plan, my major concern was with cadence
> releaeses
> > > > gone,
> > > > > the lack of a
> > > > > name/tag/version number for Cordova, and a description of its
> > contents.
> > > > > Now, this is
> > > > > addressed with CLI and package.json file.
> > > > >
> > > > > My +1 for this.
> > > > >
> > > > >
> > > > > On Fri, Jul 25, 2014 at 05:25:28PM -0400, Andrew Grieve wrote:
> > > > > > Wanted to start a thread for everyone to share what concrete
> > changes
> > > > > they'd
> > > > > > like to see happen before we start having platforms being
> released
> > in
> > > > an
> > > > > > unsynchronized fashion.
> > > > > >
> > > > > > I'll start :)
> > > > > >
> > > > > > cordova-js:
> > > > > >  - cordova.version returns a value computed from the cordova-js
> git
> > > > tag.
> > > > > >    - Let's deprecate this field
> > > > > >    - And create "cordova.platformVersion"
> > > > > >    - And update our release process to have the version set based
> > on
> > > > the
> > > > > > platform's version rather than the tag within cordova-js.
> > > > >
> > > > > What will be the value for cordova.version during deprecation
> period?
> > > > >
> > > > > >
> > > > > > Cordova-docs:
> > > > > >  - Most of the docs are not actually affected by platform
> versions.
> > > > > >  - Mainly though, it's the platform guides that are.
> > > > > >  - Two options that I see:
> > > > > >    - 1) Set default version to "edge" & always annotate with
> "added
> > > in
> > > > > > X.X.X, removed in X.X.X"
> > > > > >    - 2) Move guides to live in platform repos and link to them
> from
> > > > docs.
> > > > > >
> > > > > > cordova-cli:
> > > > > >   - Set version to 4.0.0 just to make it so that it doesn't map
> to
> > > any
> > > > > > existing platform versions
> > > > >
> > > > > Not sure if this matters. Platforms will catch up to 4.0.0 soon
> > enough.
> > > > >
> > > >
> > > > CLI version is currently "3.5.0-0.2.7-dev".  We need to change it to
> > > > something thats valid semver, and preferably somewhat compatible with
> > the
> > > > previous versions.  Choices I think are:
> > > > - 3.6.0
> > > > - 4.0.0
> > > > - A Complete reset
> > > >
> > > > I'm also in favour of 4.0.0 given those options.
> > > >
> > > > I am mildly concerned that with the looming 4.0 releases of
> platforms,
> > > > users will think this is a cad-ver update and not appreciate the
> change
> > > of
> > > > strategy, but partially think that may be a good thing too (slow
> > > > comfortable transition).
> > > >
> > > >
> > > > >
> > > > > >
> > > > > > Release Process:
> > > > > >   - Tag cordova-js for each platform release with
> > "PLATFORM-VERSION"
> > > > > >   - Rewrite
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
> > > > > > as "platforms-release-process"
> > > > >
> > > >
> > >
> >
>

Re: What's Stopping us From Independent Platform Releases

[Steven Gill <st...@gmail.com>]

New question

How does tagging and versioning for cordova-app-hello-world and
cordova-mobile-spec look in this new world of independent releases?

Currently:

1) They both get branched and tagged at the beginning of a cadence release.
2) The hello world app is supposed to be manually copied to platforms if
changes exist.

Suggestions:

A) They both get tagged independently of platforms. Won't happen often
unless they are changing (the app rarely changes).

B) They get tagged platform-version when doing a release. So mobile spec
would have a tag android-3.6.0 when we are doing the 3.6.0 release.

I think we should stop branching for these two repos. Doesn't add much
value. The tag will take us back to the state when the platform was
released.

Thoughts? Other suggestions?


On Fri, Aug 8, 2014 at 11:26 AM, Andrew Grieve <ag...@chromium.org> wrote:

> On Tue, Jul 29, 2014 at 5:00 PM, Steven Gill <st...@gmail.com>
> wrote:
>
> > Started creating issues to keep track of all of these things.
> >
> > Master issue can be seen at
> https://issues.apache.org/jira/browse/CB-7221
> >
> > Setting CLI to version 4.0.0 sounds good to me. We can mention in the
> > release blog post how platforms are on their own schedule now.
> >
> > Option 3 for docs
> > - Docs get same version as CLI & get tagged alongside cli releases
> > - We can still annotate with "added in X.X.X, removed in X.X.X" where it
> > makes sense. (like the upgrade guides)
> > - Point docs.cordova.io to edge
> > - Dropdown will show tagged versions
> > Pros:
> > - Keeps a public history of older docs at a point in time. Easy to use
> for
> > people who don't want the latest
> > - Gives us flexibility in changing docs and not worrying about older
> > versions.
> >
> > Thoughts?
> >
>
> Each new version of the docs has significant space requirements since we
> don't de-dupe images across versions or translations. Not the end of the
> world, but the repo is already > 1GB, so it is annoying.
>
> I don't think it's common that we delete docs, so maybe we could just
> create new versions when we do purges? Otherwise, the old versions of docs
> just have bugs and are strictly worse than the newest set, I think.
>
>
>
> >
> > -Steve
> >
> >
> >
> >
> >
> > On Mon, Jul 28, 2014 at 8:26 AM, Michal Mocny <mm...@chromium.org>
> wrote:
> >
> > > On Mon, Jul 28, 2014 at 5:41 AM, Gorkem Ercan <go...@gmail.com>
> > > wrote:
> > >
> > > >
> > > > This has been discussed long enough and even for those downstream
> > > > distros and tools who will have to adjust, it is better to finalize
> it.
> > > >
> > > > Overall I like the plan, my major concern was with cadence releaeses
> > > gone,
> > > > the lack of a
> > > > name/tag/version number for Cordova, and a description of its
> contents.
> > > > Now, this is
> > > > addressed with CLI and package.json file.
> > > >
> > > > My +1 for this.
> > > >
> > > >
> > > > On Fri, Jul 25, 2014 at 05:25:28PM -0400, Andrew Grieve wrote:
> > > > > Wanted to start a thread for everyone to share what concrete
> changes
> > > > they'd
> > > > > like to see happen before we start having platforms being released
> in
> > > an
> > > > > unsynchronized fashion.
> > > > >
> > > > > I'll start :)
> > > > >
> > > > > cordova-js:
> > > > >  - cordova.version returns a value computed from the cordova-js git
> > > tag.
> > > > >    - Let's deprecate this field
> > > > >    - And create "cordova.platformVersion"
> > > > >    - And update our release process to have the version set based
> on
> > > the
> > > > > platform's version rather than the tag within cordova-js.
> > > >
> > > > What will be the value for cordova.version during deprecation period?
> > > >
> > > > >
> > > > > Cordova-docs:
> > > > >  - Most of the docs are not actually affected by platform versions.
> > > > >  - Mainly though, it's the platform guides that are.
> > > > >  - Two options that I see:
> > > > >    - 1) Set default version to "edge" & always annotate with "added
> > in
> > > > > X.X.X, removed in X.X.X"
> > > > >    - 2) Move guides to live in platform repos and link to them from
> > > docs.
> > > > >
> > > > > cordova-cli:
> > > > >   - Set version to 4.0.0 just to make it so that it doesn't map to
> > any
> > > > > existing platform versions
> > > >
> > > > Not sure if this matters. Platforms will catch up to 4.0.0 soon
> enough.
> > > >
> > >
> > > CLI version is currently "3.5.0-0.2.7-dev".  We need to change it to
> > > something thats valid semver, and preferably somewhat compatible with
> the
> > > previous versions.  Choices I think are:
> > > - 3.6.0
> > > - 4.0.0
> > > - A Complete reset
> > >
> > > I'm also in favour of 4.0.0 given those options.
> > >
> > > I am mildly concerned that with the looming 4.0 releases of platforms,
> > > users will think this is a cad-ver update and not appreciate the change
> > of
> > > strategy, but partially think that may be a good thing too (slow
> > > comfortable transition).
> > >
> > >
> > > >
> > > > >
> > > > > Release Process:
> > > > >   - Tag cordova-js for each platform release with
> "PLATFORM-VERSION"
> > > > >   - Rewrite
> > > > >
> > > >
> > >
> >
> https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
> > > > > as "platforms-release-process"
> > > >
> > >
> >
>

Re: What's Stopping us From Independent Platform Releases

[Andrew Grieve <ag...@chromium.org>]

On Tue, Jul 29, 2014 at 5:00 PM, Steven Gill <st...@gmail.com> wrote:

> Started creating issues to keep track of all of these things.
>
> Master issue can be seen at https://issues.apache.org/jira/browse/CB-7221
>
> Setting CLI to version 4.0.0 sounds good to me. We can mention in the
> release blog post how platforms are on their own schedule now.
>
> Option 3 for docs
> - Docs get same version as CLI & get tagged alongside cli releases
> - We can still annotate with "added in X.X.X, removed in X.X.X" where it
> makes sense. (like the upgrade guides)
> - Point docs.cordova.io to edge
> - Dropdown will show tagged versions
> Pros:
> - Keeps a public history of older docs at a point in time. Easy to use for
> people who don't want the latest
> - Gives us flexibility in changing docs and not worrying about older
> versions.
>
> Thoughts?
>

Each new version of the docs has significant space requirements since we
don't de-dupe images across versions or translations. Not the end of the
world, but the repo is already > 1GB, so it is annoying.

I don't think it's common that we delete docs, so maybe we could just
create new versions when we do purges? Otherwise, the old versions of docs
just have bugs and are strictly worse than the newest set, I think.



>
> -Steve
>
>
>
>
>
> On Mon, Jul 28, 2014 at 8:26 AM, Michal Mocny <mm...@chromium.org> wrote:
>
> > On Mon, Jul 28, 2014 at 5:41 AM, Gorkem Ercan <go...@gmail.com>
> > wrote:
> >
> > >
> > > This has been discussed long enough and even for those downstream
> > > distros and tools who will have to adjust, it is better to finalize it.
> > >
> > > Overall I like the plan, my major concern was with cadence releaeses
> > gone,
> > > the lack of a
> > > name/tag/version number for Cordova, and a description of its contents.
> > > Now, this is
> > > addressed with CLI and package.json file.
> > >
> > > My +1 for this.
> > >
> > >
> > > On Fri, Jul 25, 2014 at 05:25:28PM -0400, Andrew Grieve wrote:
> > > > Wanted to start a thread for everyone to share what concrete changes
> > > they'd
> > > > like to see happen before we start having platforms being released in
> > an
> > > > unsynchronized fashion.
> > > >
> > > > I'll start :)
> > > >
> > > > cordova-js:
> > > >  - cordova.version returns a value computed from the cordova-js git
> > tag.
> > > >    - Let's deprecate this field
> > > >    - And create "cordova.platformVersion"
> > > >    - And update our release process to have the version set based on
> > the
> > > > platform's version rather than the tag within cordova-js.
> > >
> > > What will be the value for cordova.version during deprecation period?
> > >
> > > >
> > > > Cordova-docs:
> > > >  - Most of the docs are not actually affected by platform versions.
> > > >  - Mainly though, it's the platform guides that are.
> > > >  - Two options that I see:
> > > >    - 1) Set default version to "edge" & always annotate with "added
> in
> > > > X.X.X, removed in X.X.X"
> > > >    - 2) Move guides to live in platform repos and link to them from
> > docs.
> > > >
> > > > cordova-cli:
> > > >   - Set version to 4.0.0 just to make it so that it doesn't map to
> any
> > > > existing platform versions
> > >
> > > Not sure if this matters. Platforms will catch up to 4.0.0 soon enough.
> > >
> >
> > CLI version is currently "3.5.0-0.2.7-dev".  We need to change it to
> > something thats valid semver, and preferably somewhat compatible with the
> > previous versions.  Choices I think are:
> > - 3.6.0
> > - 4.0.0
> > - A Complete reset
> >
> > I'm also in favour of 4.0.0 given those options.
> >
> > I am mildly concerned that with the looming 4.0 releases of platforms,
> > users will think this is a cad-ver update and not appreciate the change
> of
> > strategy, but partially think that may be a good thing too (slow
> > comfortable transition).
> >
> >
> > >
> > > >
> > > > Release Process:
> > > >   - Tag cordova-js for each platform release with "PLATFORM-VERSION"
> > > >   - Rewrite
> > > >
> > >
> >
> https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
> > > > as "platforms-release-process"
> > >
> >
>

Re: What's Stopping us From Independent Platform Releases

[Steven Gill <st...@gmail.com>]

Started creating issues to keep track of all of these things.

Master issue can be seen at https://issues.apache.org/jira/browse/CB-7221

Setting CLI to version 4.0.0 sounds good to me. We can mention in the
release blog post how platforms are on their own schedule now.

Option 3 for docs
- Docs get same version as CLI & get tagged alongside cli releases
- We can still annotate with "added in X.X.X, removed in X.X.X" where it
makes sense. (like the upgrade guides)
- Point docs.cordova.io to edge
- Dropdown will show tagged versions
Pros:
- Keeps a public history of older docs at a point in time. Easy to use for
people who don't want the latest
- Gives us flexibility in changing docs and not worrying about older
versions.

Thoughts?

-Steve





On Mon, Jul 28, 2014 at 8:26 AM, Michal Mocny <mm...@chromium.org> wrote:

> On Mon, Jul 28, 2014 at 5:41 AM, Gorkem Ercan <go...@gmail.com>
> wrote:
>
> >
> > This has been discussed long enough and even for those downstream
> > distros and tools who will have to adjust, it is better to finalize it.
> >
> > Overall I like the plan, my major concern was with cadence releaeses
> gone,
> > the lack of a
> > name/tag/version number for Cordova, and a description of its contents.
> > Now, this is
> > addressed with CLI and package.json file.
> >
> > My +1 for this.
> >
> >
> > On Fri, Jul 25, 2014 at 05:25:28PM -0400, Andrew Grieve wrote:
> > > Wanted to start a thread for everyone to share what concrete changes
> > they'd
> > > like to see happen before we start having platforms being released in
> an
> > > unsynchronized fashion.
> > >
> > > I'll start :)
> > >
> > > cordova-js:
> > >  - cordova.version returns a value computed from the cordova-js git
> tag.
> > >    - Let's deprecate this field
> > >    - And create "cordova.platformVersion"
> > >    - And update our release process to have the version set based on
> the
> > > platform's version rather than the tag within cordova-js.
> >
> > What will be the value for cordova.version during deprecation period?
> >
> > >
> > > Cordova-docs:
> > >  - Most of the docs are not actually affected by platform versions.
> > >  - Mainly though, it's the platform guides that are.
> > >  - Two options that I see:
> > >    - 1) Set default version to "edge" & always annotate with "added in
> > > X.X.X, removed in X.X.X"
> > >    - 2) Move guides to live in platform repos and link to them from
> docs.
> > >
> > > cordova-cli:
> > >   - Set version to 4.0.0 just to make it so that it doesn't map to any
> > > existing platform versions
> >
> > Not sure if this matters. Platforms will catch up to 4.0.0 soon enough.
> >
>
> CLI version is currently "3.5.0-0.2.7-dev".  We need to change it to
> something thats valid semver, and preferably somewhat compatible with the
> previous versions.  Choices I think are:
> - 3.6.0
> - 4.0.0
> - A Complete reset
>
> I'm also in favour of 4.0.0 given those options.
>
> I am mildly concerned that with the looming 4.0 releases of platforms,
> users will think this is a cad-ver update and not appreciate the change of
> strategy, but partially think that may be a good thing too (slow
> comfortable transition).
>
>
> >
> > >
> > > Release Process:
> > >   - Tag cordova-js for each platform release with "PLATFORM-VERSION"
> > >   - Rewrite
> > >
> >
> https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
> > > as "platforms-release-process"
> >
>

Re: What's Stopping us From Independent Platform Releases

[Michal Mocny <mm...@chromium.org>]

On Mon, Jul 28, 2014 at 5:41 AM, Gorkem Ercan <go...@gmail.com>
wrote:

>
> This has been discussed long enough and even for those downstream
> distros and tools who will have to adjust, it is better to finalize it.
>
> Overall I like the plan, my major concern was with cadence releaeses gone,
> the lack of a
> name/tag/version number for Cordova, and a description of its contents.
> Now, this is
> addressed with CLI and package.json file.
>
> My +1 for this.
>
>
> On Fri, Jul 25, 2014 at 05:25:28PM -0400, Andrew Grieve wrote:
> > Wanted to start a thread for everyone to share what concrete changes
> they'd
> > like to see happen before we start having platforms being released in an
> > unsynchronized fashion.
> >
> > I'll start :)
> >
> > cordova-js:
> >  - cordova.version returns a value computed from the cordova-js git tag.
> >    - Let's deprecate this field
> >    - And create "cordova.platformVersion"
> >    - And update our release process to have the version set based on the
> > platform's version rather than the tag within cordova-js.
>
> What will be the value for cordova.version during deprecation period?
>
> >
> > Cordova-docs:
> >  - Most of the docs are not actually affected by platform versions.
> >  - Mainly though, it's the platform guides that are.
> >  - Two options that I see:
> >    - 1) Set default version to "edge" & always annotate with "added in
> > X.X.X, removed in X.X.X"
> >    - 2) Move guides to live in platform repos and link to them from docs.
> >
> > cordova-cli:
> >   - Set version to 4.0.0 just to make it so that it doesn't map to any
> > existing platform versions
>
> Not sure if this matters. Platforms will catch up to 4.0.0 soon enough.
>

CLI version is currently "3.5.0-0.2.7-dev".  We need to change it to
something thats valid semver, and preferably somewhat compatible with the
previous versions.  Choices I think are:
- 3.6.0
- 4.0.0
- A Complete reset

I'm also in favour of 4.0.0 given those options.

I am mildly concerned that with the looming 4.0 releases of platforms,
users will think this is a cad-ver update and not appreciate the change of
strategy, but partially think that may be a good thing too (slow
comfortable transition).


>
> >
> > Release Process:
> >   - Tag cordova-js for each platform release with "PLATFORM-VERSION"
> >   - Rewrite
> >
> https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
> > as "platforms-release-process"
>

Re: What's Stopping us From Independent Platform Releases

[Gorkem Ercan <go...@gmail.com>]

This has been discussed long enough and even for those downstream
distros and tools who will have to adjust, it is better to finalize it. 

Overall I like the plan, my major concern was with cadence releaeses gone, the lack of a
name/tag/version number for Cordova, and a description of its contents. Now, this is 
addressed with CLI and package.json file.

My +1 for this. 


On Fri, Jul 25, 2014 at 05:25:28PM -0400, Andrew Grieve wrote:
> Wanted to start a thread for everyone to share what concrete changes they'd
> like to see happen before we start having platforms being released in an
> unsynchronized fashion.
> 
> I'll start :)
> 
> cordova-js:
>  - cordova.version returns a value computed from the cordova-js git tag.
>    - Let's deprecate this field
>    - And create "cordova.platformVersion"
>    - And update our release process to have the version set based on the
> platform's version rather than the tag within cordova-js.

What will be the value for cordova.version during deprecation period?

> 
> Cordova-docs:
>  - Most of the docs are not actually affected by platform versions.
>  - Mainly though, it's the platform guides that are.
>  - Two options that I see:
>    - 1) Set default version to "edge" & always annotate with "added in
> X.X.X, removed in X.X.X"
>    - 2) Move guides to live in platform repos and link to them from docs.
> 
> cordova-cli:
>   - Set version to 4.0.0 just to make it so that it doesn't map to any
> existing platform versions

Not sure if this matters. Platforms will catch up to 4.0.0 soon enough.

> 
> Release Process:
>   - Tag cordova-js for each platform release with "PLATFORM-VERSION"
>   - Rewrite
> https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
> as "platforms-release-process"

Re: What's Stopping us From Independent Platform Releases

[Carlos Santana <cs...@gmail.com>]

Andrew
  Good catch on cordova-js, +1

Steve
  We also need to be very clear about which versions are pinned to cli.
Communicate that to our users in tools release blog posts and maybe some
config file?

Not config file, communicate on the package.json (and maybe in README.md if
not very clear that is in pacakge,json of the cordova node module)
Also CLI will use the values from package.json to know the version of the
platform to download if one is not provided, this is the data that is
located today in platforms.js in [1] (don't be confuse with with
platform.js in the same directory :-) )  is just surfacing to be more clear
what will the CLI use

[1]:
https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/platforms.js






On Fri, Jul 25, 2014 at 8:24 PM, Steven Gill <st...@gmail.com> wrote:

> We should give some notice about version change since some downstream dists
> or tools might rely on cadver-semver.
>
> I can write a blog post next week about it.
>
> We also need to be very clear about which versions are pinned to cli.
> Communicate that to our users in tools release blog posts and maybe some
> config file?
>
> What about removing platform specific stuff from cli? If we manage to dumb
> down the cli now, it will hopefully remove potential compatability issues
> later for platforms and cli. That might matter if we want to preserve older
> clis supporting newer platforms.
>
> Summarizing version changes at releases (if I understood this correctly)
> - Platforms release independently.
> - A tools release follows a platform release. Pinning the new platform. If
> the platform was a major release, cli version takes a major bump
> (ex Cordova-android goes to 4.0.0, cli goes to 6.0.0). If minor or patch
> release for platform, cli version reflects that (ex android 4.1.1, cli
> 6.5.1)
> - cli version will increase at a much faster pace than platforms. That's
> fine and expected. This is because it has to take changes from all
> platforms.
>
>
>
>
>
>
>
>
>
> On Friday, July 25, 2014, Andrew Grieve <ag...@chromium.org> wrote:
>
> > On Fri, Jul 25, 2014 at 7:03 PM, Brian LeRoux <b@brian.io
> <javascript:;>>
> > wrote:
> >
> > > > cordova-js:
> > > >  - cordova.version returns a value computed from the cordova-js git
> > tag.
> > > >    - Let's deprecate this field
> > > >    - And create "cordova.platformVersion"
> > > >    - And update our release process to have the version set based on
> > the
> > > > platform's version rather than the tag within cordova-js.
> > > >
> > > >
> > > This is a very good idea. +1
> > >
> > >
> > >
> > > > Cordova-docs:
> > > >  - Most of the docs are not actually affected by platform versions.
> > > >  - Mainly though, it's the platform guides that are.
> > > >  - Two options that I see:
> > > >    - 1) Set default version to "edge" & always annotate with "added
> in
> > > > X.X.X, removed in X.X.X"
> > > >    - 2) Move guides to live in platform repos and link to them from
> > docs.
> > > >
> > > >
> > > Think both are good ideas also. Going to edge for docs should be easy
> > > enough. #2 means someone would have to look at the docs gen ...which I
> > guess
> > > isn't as terrible now that we have a Vagrantfile in there.
> > >
> > >
> > >
> > > > cordova-cli:
> > > >   - Set version to 4.0.0 just to make it so that it doesn't map to
> any
> > > > existing platform versions
> > > >
> > > >
> > > you mean start a 4.x release branch ? (kinda hope we can ship this
> sooner
> > > than later to help it bake.)
> > >
> > I just mean drop the CadVer-SemVer scheme.
> >
> >
> > >
> > >
> > >
> > > > Release Process:
> > > >   - Tag cordova-js for each platform release with "PLATFORM-VERSION"
> > > >   - Rewrite
> > > >
> > > >
> > >
> >
> https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
> > > > as "platforms-release-process"
> > > >
> > >
> > > +1
> > >
> >
>



-- 
Carlos Santana
<cs...@gmail.com>

Re: What's Stopping us From Independent Platform Releases

[Steven Gill <st...@gmail.com>]

We should give some notice about version change since some downstream dists
or tools might rely on cadver-semver.

I can write a blog post next week about it.

We also need to be very clear about which versions are pinned to cli.
Communicate that to our users in tools release blog posts and maybe some
config file?

What about removing platform specific stuff from cli? If we manage to dumb
down the cli now, it will hopefully remove potential compatability issues
later for platforms and cli. That might matter if we want to preserve older
clis supporting newer platforms.

Summarizing version changes at releases (if I understood this correctly)
- Platforms release independently.
- A tools release follows a platform release. Pinning the new platform. If
the platform was a major release, cli version takes a major bump
(ex Cordova-android goes to 4.0.0, cli goes to 6.0.0). If minor or patch
release for platform, cli version reflects that (ex android 4.1.1, cli
6.5.1)
- cli version will increase at a much faster pace than platforms. That's
fine and expected. This is because it has to take changes from all
platforms.









On Friday, July 25, 2014, Andrew Grieve <ag...@chromium.org> wrote:

> On Fri, Jul 25, 2014 at 7:03 PM, Brian LeRoux <b@brian.io <javascript:;>>
> wrote:
>
> > > cordova-js:
> > >  - cordova.version returns a value computed from the cordova-js git
> tag.
> > >    - Let's deprecate this field
> > >    - And create "cordova.platformVersion"
> > >    - And update our release process to have the version set based on
> the
> > > platform's version rather than the tag within cordova-js.
> > >
> > >
> > This is a very good idea. +1
> >
> >
> >
> > > Cordova-docs:
> > >  - Most of the docs are not actually affected by platform versions.
> > >  - Mainly though, it's the platform guides that are.
> > >  - Two options that I see:
> > >    - 1) Set default version to "edge" & always annotate with "added in
> > > X.X.X, removed in X.X.X"
> > >    - 2) Move guides to live in platform repos and link to them from
> docs.
> > >
> > >
> > Think both are good ideas also. Going to edge for docs should be easy
> > enough. #2 means someone would have to look at the docs gen ...which I
> guess
> > isn't as terrible now that we have a Vagrantfile in there.
> >
> >
> >
> > > cordova-cli:
> > >   - Set version to 4.0.0 just to make it so that it doesn't map to any
> > > existing platform versions
> > >
> > >
> > you mean start a 4.x release branch ? (kinda hope we can ship this sooner
> > than later to help it bake.)
> >
> I just mean drop the CadVer-SemVer scheme.
>
>
> >
> >
> >
> > > Release Process:
> > >   - Tag cordova-js for each platform release with "PLATFORM-VERSION"
> > >   - Rewrite
> > >
> > >
> >
> https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
> > > as "platforms-release-process"
> > >
> >
> > +1
> >
>

Re: What's Stopping us From Independent Platform Releases

[Andrew Grieve <ag...@chromium.org>]

On Fri, Jul 25, 2014 at 7:03 PM, Brian LeRoux <b...@brian.io> wrote:

> > cordova-js:
> >  - cordova.version returns a value computed from the cordova-js git tag.
> >    - Let's deprecate this field
> >    - And create "cordova.platformVersion"
> >    - And update our release process to have the version set based on the
> > platform's version rather than the tag within cordova-js.
> >
> >
> This is a very good idea. +1
>
>
>
> > Cordova-docs:
> >  - Most of the docs are not actually affected by platform versions.
> >  - Mainly though, it's the platform guides that are.
> >  - Two options that I see:
> >    - 1) Set default version to "edge" & always annotate with "added in
> > X.X.X, removed in X.X.X"
> >    - 2) Move guides to live in platform repos and link to them from docs.
> >
> >
> Think both are good ideas also. Going to edge for docs should be easy
> enough. #2 means someone would have to look at the docs gen …which I guess
> isn't as terrible now that we have a Vagrantfile in there.
>
>
>
> > cordova-cli:
> >   - Set version to 4.0.0 just to make it so that it doesn't map to any
> > existing platform versions
> >
> >
> you mean start a 4.x release branch ? (kinda hope we can ship this sooner
> than later to help it bake.)
>
I just mean drop the CadVer-SemVer scheme.


>
>
>
> > Release Process:
> >   - Tag cordova-js for each platform release with "PLATFORM-VERSION"
> >   - Rewrite
> >
> >
> https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
> > as "platforms-release-process"
> >
>
> +1
>

Re: What's Stopping us From Independent Platform Releases

[Brian LeRoux <b...@brian.io>]

> cordova-js:
>  - cordova.version returns a value computed from the cordova-js git tag.
>    - Let's deprecate this field
>    - And create "cordova.platformVersion"
>    - And update our release process to have the version set based on the
> platform's version rather than the tag within cordova-js.
>
>
This is a very good idea. +1



> Cordova-docs:
>  - Most of the docs are not actually affected by platform versions.
>  - Mainly though, it's the platform guides that are.
>  - Two options that I see:
>    - 1) Set default version to "edge" & always annotate with "added in
> X.X.X, removed in X.X.X"
>    - 2) Move guides to live in platform repos and link to them from docs.
>
>
Think both are good ideas also. Going to edge for docs should be easy
enough. #2 means someone would have to look at the docs gen …which I guess
isn't as terrible now that we have a Vagrantfile in there.



> cordova-cli:
>   - Set version to 4.0.0 just to make it so that it doesn't map to any
> existing platform versions
>
>
you mean start a 4.x release branch ? (kinda hope we can ship this sooner
than later to help it bake.)



> Release Process:
>   - Tag cordova-js for each platform release with "PLATFORM-VERSION"
>   - Rewrite
>
> https://github.com/apache/cordova-coho/blob/master/docs/cadence-release-process.md
> as "platforms-release-process"
>

+1