cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: tag 3.0.0rc1 on Monday the 15th
Date Mon, 15 Jul 2013 19:02:22 GMT
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
View raw message