cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: What's Stopping us From Independent Platform Releases
Date Thu, 14 Aug 2014 13:43:22 GMT
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"
> > > > > >
> > > > >
> > > >
> > >
> >
>

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