cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: tag 3.0.0rc1 on Monday the 15th
Date Mon, 15 Jul 2013 16:03:49 GMT
The Apache Way was a part of what I was thinking as well.

Also - it occurs to me that we'll have to change our voting system when it
comes to plugins since each plugin repo should have a +1 from each platform
maintainer, and can be tagged only once.


On Fri, Jul 12, 2013 at 12:53 PM, Joe Bowser <bowserj@gmail.com> wrote:

> Don't we have to release a zip on an Apache server because of "The
> Apache Way"?  That's why I thought we had to release artifacts, not
> for people, but for process.
>
> On Fri, Jul 12, 2013 at 9:31 AM, Brian LeRoux <b@brian.io> wrote:
> > I don't mind this but it seems like a lot of work to release artifacts
> > for...who? End users we want to encourage to use the tooling golden
> > path for creating projects, working w/ plugins, etc.
> >
> > If anything I'd rather we *only* distribute cordova-cli as the
> > canonical repo and entry point for usage and treat the rest as our
> > project build artifacts/ephemera.
> >
> > Way easier. Way more in tune w/ actual usage.
> >
> >
> >
> > On Fri, Jul 12, 2013 at 7:25 AM, Andrew Grieve <agrieve@chromium.org>
> wrote:
> >> Definitely would like to get everything Release / Versioning related
> >> documented on the wiki. The most complete source right now is:
> >> http://wiki.apache.org/cordova/CuttingReleases We should add another
> page
> >> for versioning once we settle on what to do with plugins.
> >>
> >> Right now only CLI & Plugman are distributed on npm and are versioned
> >> separately. Nothing else is on npm though, so package.json isn't used.
> >> Instead VERSION files hold the version.
> >>
> >> I've decided I didn't like my previous proposal of not updating versions
> >> when things don't change because it will make it harder to check out a
> >> version of Cordova.
> >>
> >> New Proposal:
> >>
> >> 1. Each Cordova release will include:
> >>  - A copy of every repo, including all core plugins.
> >>
> >> 2. Each plugin repo will get a release branch even if the code hasn't
> >> changed.
> >>
> >> 3. Each plugin's version will match the Cordova version
> >>
> >> 4. Plugins can have separate point releases if they are important
> updates
> >> to them. These will be in the form of tags along the release branch.
> >>
> >> 5. As soon as release branches are created, we change the VERSION file
> and
> >> re-tag master to a -dev version of the next release (e.g. 3.1.0-dev)
> >>
> >>
> >> On Thu, Jul 11, 2013 at 9:05 AM, Carlos Santana <csantana23@gmail.com
> >wrote:
> >>
> >>> Dumb questions
> >>>
> >>> Does the package.json {version:""} field needs to be updated on every
> >>> commit to the repo?
> >>>   (meaning depending what is the commit, then the major, minor, patch,
> or
> >>> extension gets updated)
> >>> Does the npm registry support pre-release and build metadata (i.e.
> x.7.z.92
> >>> in 2.9.1-x.7.z.92)?
> >>> If this true, Does npm knows to install the latest stable version, but
> user
> >>> can request a pre-release by specifying the version that it wants @2
> >>> .9.1-x.7.z.92
> >>>
> >>>
> >>>
> >>> Refs:
> >>> http://semver.org/
> >>>
> >>> Given a version number MAJOR.MINOR.PATCH, increment the:
> >>>
> >>>    1. MAJOR version when you make incompatible API changes,
> >>>    2. MINOR version when you add functionality in a
> backwards-compatible
> >>>    manner, and
> >>>    3. PATCH version when you make backwards-compatible bug fixes.
> >>>
> >>> *Additional labels for pre-release and build metadata are available as
> >>> extensions to the MAJOR.MINOR.PATCH format.*
> >>>
> >>>
> >>> On Thu, Jul 11, 2013 at 8:57 AM, Carlos Santana <csantana23@gmail.com
> >>> >wrote:
> >>>
> >>> > About versioning maybe we should open a mail-thread/jira/wikipage
> (not
> >>> > familiar with process yet :-))
> >>> > To discuss and be clear what is the guideline/process to version
> >>> different
> >>> > components.
> >>> >
> >>> > Some thoughts (maybe this is already well understood and documented
> in
> >>> > wiki):
> >>> > - Lets follow semantic versioning as much as possible for ALL
> components
> >>> > (i.e. plugins, core, cli, plugman, platform, repos)
> >>> > - Document the deliverables/releases channels (i.e. npm, apache
> zip/dist,
> >>> > git repo)
> >>> > - Maintain the versions in sync (package.json {version:""}, git tag)
> >>> > tag/hash should match what's posted in npm registry?
> >>> >
> >>> > --Carlos
> >>> >
> >>> >
> >>> > On Wed, Jul 10, 2013 at 7:33 PM, Andrew Grieve <agrieve@chromium.org
> >>> >wrote:
> >>> >
> >>> >> Coho started as just a tool to package, but has grown into a tool
> that:
> >>> >> a) helps work with multiple repos
> >>> >> b) documents our release process in working code.
> >>> >>
> >>> >> re windows tagging - As of the last release bug template, we're
> tagging
> >>> >> each branch individually either via coho or not, so no issue there.
> It
> >>> >> won't be tagged by coho unless someone does it explicitly. I think
> we
> >>> can
> >>> >> still use it to create the windows release branches, since if it
> messes
> >>> up
> >>> >> we can just fix what it missed (but all it does is update VERSION
> and
> >>> >> cordova.js).
> >>> >>
> >>> >> As for plugins, I've only used CLI by pointing at directories so
> far,
> >>> but
> >>> >> I
> >>> >> was under the impression that if you give it a URL, you have to
> give it
> >>> a
> >>> >> repo + subdirectory + hash/tag combination. If it's currently just
> >>> >> installing from master, I think that's a bad default and should
> instead
> >>> go
> >>> >> by a tag (npm goes by the "stable" tag by default I believe). So...
> we
> >>> >> will
> >>> >> need an explicit action for commits to a plugin to be picked up
by
> >>> >> plugman.
> >>> >>
> >>> >> How about if a plugin has a commit that is urgent, it gets a point
> >>> release
> >>> >> right away. Otherwise, it waits for the next Cordova release cycle.
> >>> >>
> >>> >>
> >>> >>
> >>> >> On Wed, Jul 10, 2013 at 6:47 PM, Jesse <purplecabbage@gmail.com>
> wrote:
> >>> >>
> >>> >> > re: COHO
> >>> >> > I cannot guarantee the output of windows/phone releases if
they
> are
> >>> >> tagged
> >>> >> > and updated via coho. I like the idea of having continuous
> >>> integration,
> >>> >> but
> >>> >> > this is not there yet.  I would prefer for now to manually
update
> and
> >>> >> tag
> >>> >> > wp7+wp8+windows8 repos because I do not currently trust the
magic
> in
> >>> >> coho,
> >>> >> > and do not have time to go and understand all of the magic.
> >>> >> >
> >>> >> > @purplecabbage
> >>> >> > risingj.com
> >>> >> >
> >>> >> >
> >>> >> > On Wed, Jul 10, 2013 at 3:36 PM, Steven Gill <
> stevengill97@gmail.com>
> >>> >> > wrote:
> >>> >> >
> >>> >> > > Plugin versioning is definitely something we need to
discuss in
> >>> >> detail.
> >>> >> > >
> >>> >> > > What happens if I make a change to the camera plugin.
Do I
> >>> immediately
> >>> >> > bump
> >>> >> > > the version? Probably not. But people who install it
using
> >>> plugman/cli
> >>> >> > > after the change will get the latest one on master with
no
> obvious
> >>> >> > > difference to them. Version wise it is the same as before
the
> >>> change.
> >>> >> > This
> >>> >> > > feels wrong.
> >>> >> > >
> >>> >> > > We can now update plugins independently of our once a
month
> release
> >>> >> and
> >>> >> > get
> >>> >> > > those updates to our users instantly. I think we should
update
> the
> >>> >> > version
> >>> >> > > of the plugins after every change. Similar to node-modules
on
>  npm.
> >>> >> > >
> >>> >> > > Coho is not just for packaging. I love the fact that
I can
> clone and
> >>> >> > update
> >>> >> > > all of the repos in a few quick commands. Coho seems
to have the
> >>> >> ability
> >>> >> > to
> >>> >> > > do tagging, release packaging and signing, uploading
releases to
> >>> >> apache,
> >>> >> > > cloning all repos and soon generating release issues
on jira. It
> >>> will
> >>> >> be
> >>> >> > > important to solve all of the issues people are having
with
> coho and
> >>> >> > > document what you can do with it.
> >>> >> > >
> >>> >> > >
> >>> >> > > On Wed, Jul 10, 2013 at 3:15 PM, Joe Bowser <bowserj@gmail.com>
> >>> >> wrote:
> >>> >> > >
> >>> >> > > > I'm going to create a new thread about this, but
what's the
> >>> purpose
> >>> >> of
> >>> >> > > > coho again? I thought it was just for packaging
releases.
> >>> >> > > >
> >>> >> > > > On Wed, Jul 10, 2013 at 3:07 PM, Andrew Grieve <
> >>> >> agrieve@chromium.org>
> >>> >> > > > wrote:
> >>> >> > > > > Our intern Jeffrey is actively working on adding
a command
> to
> >>> >> coho to
> >>> >> > > be
> >>> >> > > > > able to create release bugs (based off of cordova-labs).
If
> he
> >>> >> gets
> >>> >> > > done,
> >>> >> > > > > by Monday, then it'll be a cinch to create
the issues.
> >>> >> > > > >
> >>> >> > > > > We could maybe start by discussing what we
want to do with
> the
> >>> >> plugin
> >>> >> > > > repos
> >>> >> > > > > for the release.
> >>> >> > > > >
> >>> >> > > > > Should they all have release branches?
> >>> >> > > > > Should they be versioned the same? e.g. 3.0.x,
or should
> they
> >>> >> start
> >>> >> > out
> >>> >> > > > at
> >>> >> > > > > 1.0.x?
> >>> >> > > > > Are we including a .zip of all of them in our
apache
> >>> distribution
> >>> >> > .zip?
> >>> >> > > > >
> >>> >> > > > >
> >>> >> > > > > Here's a stab at it from me:
> >>> >> > > > >
> >>> >> > > > > - Always include all core plugins in the apache
release .zip
> >>> >> > > > > - If a plugin has not changed since the previous
release,
> then
> >>> >> just
> >>> >> > put
> >>> >> > > > in
> >>> >> > > > > the previous release of the .zip.
> >>> >> > > > >    - E.g. for 3.1.0, if plugin-console has
no changes, then
> just
> >>> >> > > package
> >>> >> > > > > version 3.0.0 of the plugin in the release
> >>> >> > > > > - Create release branches for the plugin repos
only if
> there has
> >>> >> > been a
> >>> >> > > > > commit since the previous release
> >>> >> > > > >    - If there were no commits, then there cannot
be any
> >>> >> regressions,
> >>> >> > so
> >>> >> > > > no
> >>> >> > > > > need for a release branch.
> >>> >> > > > > - I think they should be versioned the same
to help us
> figure
> >>> out
> >>> >> > when
> >>> >> > > > the
> >>> >> > > > > last change was.
> >>> >> > > > >    - This could mean that if plugin-console
goes three
> months
> >>> >> > without a
> >>> >> > > > > change, it will go from 3.0.0 straight to 3.3.0
> >>> >> > > > >
> >>> >> > > > >
> >>> >> > > > >
> >>> >> > > > >
> >>> >> > > > >
> >>> >> > > > >
> >>> >> > > > > On Wed, Jul 10, 2013 at 5:50 PM, Filip Maj
<fil@adobe.com>
> >>> wrote:
> >>> >> > > > >
> >>> >> > > > >> Yeah.. Maybe we should create the issues
for the rc soon?
> >>> >> > > > >>
> >>> >> > > > >> On 7/10/13 1:57 PM, "Andrew Grieve" <agrieve@chromium.org>
> >>> >> wrote:
> >>> >> > > > >>
> >>> >> > > > >> >I would put that at next week unless
someone has cycles
> to get
> >>> >> on
> >>> >> > it
> >>> >> > > > this
> >>> >> > > > >> >week.
> >>> >> > > > >> >
> >>> >> > > > >> >
> >>> >> > > > >> >On Wed, Jul 10, 2013 at 4:24 PM, Marcel
Kinard <
> >>> >> cmarcelk@gmail.com
> >>> >> > >
> >>> >> > > > >> wrote:
> >>> >> > > > >> >
> >>> >> > > > >> >> When will the Upgrade Guides (2.9
-> 3.0) be written?
> That
> >>> >> > content
> >>> >> > > is
> >>> >> > > > >> >> currently not in cordova-docs.
> >>> >> > > > >>
> >>> >> > > > >>
> >>> >> > > >
> >>> >> > >
> >>> >> >
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Carlos Santana
> >>> > <csantana23@gmail.com>
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Carlos Santana
> >>> <csantana23@gmail.com>
> >>>
>

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