cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: tag 3.0.0rc1 on Monday the 15th
Date Fri, 12 Jul 2013 16:31:58 GMT
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