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 <csantan...@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 <agri...@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 <purplecabb...@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 <stevengil...@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 <bows...@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 <
>> agri...@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 <f...@adobe.com> wrote:
>> > > > >
>> > > > >> Yeah.. Maybe we should create the issues for the rc soon?
>> > > > >>
>> > > > >> On 7/10/13 1:57 PM, "Andrew Grieve" <agri...@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 <
>> cmarc...@gmail.com
>> > >
>> > > > >> wrote:
>> > > > >> >
>> > > > >> >> When will the Upgrade Guides (2.9 -> 3.0) be written? That
>> > content
>> > > is
>> > > > >> >> currently not in cordova-docs.
>> > > > >>
>> > > > >>
>> > > >
>> > >
>> >
>>
>
>
>
> --
> Carlos Santana
> <csantan...@gmail.com>
>
--
Carlos Santana
<csantan...@gmail.com>
