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 23:10:36 GMT
On Mon, Jul 15, 2013 at 5:22 PM, Steven Gill <stevengill97@gmail.com> wrote:

> We will need to add issues for tagging plugins.

What's your reasoning?



> I can create the issue and
> tag the plugins. I figure for now, plugins will use same tagging process as
> other repos.
>
And that process is?

For the RC - it's trivial to create release branches and an RC tag. coho
can do it in bulk. The main question is what criteria should we use to
determine whether a plugin is ready for tagging? For an RC, we could just
tag with whatever's there , but then it's not really adding any meaning on
top of the release branch existing. I think the thing that separates the
release branch from the tag is some testing.


>
>
> On Mon, Jul 15, 2013 at 12:02 PM, Filip Maj <fil@adobe.com> wrote:
>
> > Created the issues: https://issues.apache.org/jira/browse/CB-4208
> >
> > On 7/15/13 11:56 AM, "Joe Bowser" <bowserj@gmail.com> wrote:
> >
> > >So, for tagging today, can we get the issues setup and the JS tagged
> > >at least? We can somehow muddle through this RC1.
> > >
> > >On Mon, Jul 15, 2013 at 9:48 AM, Brian LeRoux <b@brian.io> wrote:
> > >> I'd say we could consider the core plugins as build ephemera not
> > >> unlike docs or automations. Really cordova-cli is the main point of
> > >> interaction between us and our developer community.
> > >>
> > >>
> > >> On Mon, Jul 15, 2013 at 9:03 AM, Andrew Grieve <agrieve@chromium.org>
> > >>wrote:
> > >>> 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