cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Gill <stevengil...@gmail.com>
Subject Re: What's Stopping us From Independent Platform Releases
Date Tue, 29 Jul 2014 21:00:27 GMT
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 <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"
> >
>

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