cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Brooks <mich...@michaelbrooks.ca>
Subject Re: Storing Version Numbers
Date Wed, 14 Aug 2013 21:09:10 GMT
The proposal is good from the CLI and Docs point-of-view.


On Wed, Aug 14, 2013 at 1:59 PM, Jesse <purplecabbage@gmail.com> wrote:

> The reason for having the git hash inside cordova-js is because the build
> output is then taken and placed into other projects, so this makes it
> possible to go and figure out where things went out of sync. So I think it
> should remain there.
> I only really care about having the VERSION around for the individual
> platforms.  In my mind, plugman/cli/plugins can do their own thing. (
> especially plugins  )
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Wed, Aug 14, 2013 at 1:25 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
>
> > On Wed, Aug 14, 2013 at 4:09 PM, Jesse <purplecabbage@gmail.com> wrote:
> >
> > > windows8 + wp7 and wp8 all have the version script as well, but it
> simply
> > > echos the content of the ../VERSION file
> > > Currently the dev branch has a VERSION of 0.0.0 because I needed it to
> > be a
> > > valid version number format for other things.
> > >
> > > I like the transparency of simply having a VERSION file at the root of
> > any
> > > cordova project.
> >
> > I actually liked this too, but the problem is that it can be out of sync
> > with other sources of the VERSION.
> > For plugman/cli/plugins, I think it's still quite discoverable being kept
> > in the package.json / plugin.xml files.
> > For cordova-js & platforms, I think we could just as easily keep the
> > VERSION files and add logic to grunt / create scripts to read the file.
> > Thoughts?
> >
> >
> >
> > > Can't we just remove the extra steps with the git hash
> > > checking?
> > >
> > The git hash part is gone for platforms. Are you suggesting removing that
> > from cordova-js as well?
> >
> >
> > >
> > >
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > >
> > > On Wed, Aug 14, 2013 at 12:44 PM, Filip Maj <fil@adobe.com> wrote:
> > >
> > > > Looks good to me!
> > > >
> > > > On 8/14/13 11:49 AM, "Andrew Grieve" <agrieve@chromium.org> wrote:
> > > >
> > > > >Ian's put together a wiki page on how to store version numbers in
> our
> > > > >repos:
> > > > >https://wiki.apache.org/cordova/PlatformVersionScripts
> > > > >
> > > > >I'd like to add info to it for non-platform repos as well, but want
> to
> > > > >draw
> > > > >everyone's attention to it on the ML so that we can have easier
> > comments
> > > > >about it:
> > > > >
> > > > >
> > > > >= All Repositories =
> > > > >'''Proposal'''
> > > > >VERSION files go away. None of the below schemes use them, so they
> > > should
> > > > >be added only when building Apache release .zips.
> > > > >
> > > > >= Cordova platforms =
> > > > >
> > > > >Cordova platforms should have a simple, reliable method to report
> > their
> > > > >version number, for use by automated tools such as CLI and plugman.
> > > > >
> > > > >The current method for doing this (supported by Android; support
> > coming
> > > > >for
> > > > >other platforms) is to have a script in the platform package, under
> > > > >`bin/templates/cordova/version`, which can be called to report the
> > > version
> > > > >number.
> > > > >
> > > > >Previously, this file would, on some platforms, go through some
> rather
> > > > >complicated process to infer the correct version number (such as
> > > checking
> > > > >the git hash of the included cordova.js file). It will be simpler
> and
> > > > >easier to maintain to have this file simply echo a string constant.
> > > > >
> > > > >The version number should correspond closely to the git branch.
> When a
> > > > >release branch is made, both the branch and the master branch should
> > be
> > > > >updated. The master branch should *always* have a version number
> > ending
> > > in
> > > > >"-dev", which indicates the version currently being developed. A
> fresh
> > > > >release branch should change the version to an "-rc1" version, and
> > then
> > > > >change to the unqualified version number when it is released.
> > > > >
> > > > >(This constant version number can be updated manually, but *should*
> > > > >eventually be updated via coho as release branches are made.)
> > > > >
> > > > >This should give a rough idea how the version number should advance:
> > > > >
> > > > >{{{
> > > > >         3.3.0-dev
> > > > > 3.2.0-dev|
> > > > >  |       |
> > > > >--A---B---C---D (master)
> > > > >       \
> > > > >        \--E---F---G---H (3.2.x)
> > > > >           |       |   |
> > > > >          3.2.0-rc1|  3.2.1-rc1
> > > > >                  3.2.0
> > > > >}}}
> > > > >
> > > > > * A: This is on the master branch, after 3.1.x has been branched,
> as
> > > 3.2
> > > > >is being developed.
> > > > > * B: This is the branch point for 3.2.x
> > > > > * C: The first commit after 3.2.x is branched should identify the
> > > master
> > > > >branch as 3.3 is being developed on master now.
> > > > > * E: The first commit on the 3.2.x branch should identify the
> branch
> > as
> > > > >3.2.0-rc1
> > > > > * G: At some point, 3.2.0 is released, and should be identified as
> > such
> > > > > * H: After 3.2.0 is released, any further development can be called
> > > > >3.2.1-rc1
> > > > >
> > > > >Current support:
> > > > >
> > > > >||'''Platform'''||'''Support'''||
> > > > >||Android       || {*}         ||
> > > > >||BB10          || {o}         ||
> > > > >||iOS           || {o}         ||
> > > > >||OSX           || {o}         ||
> > > > >||QT            || {o}         ||
> > > > >||Tizen         || {o}         ||
> > > > >||WebOS         || {o}         ||
> > > > >||Win           || {o}         ||
> > > > >||WP7           || {o}         ||
> > > > >||WP8           || {o}         ||
> > > > >||www           || {o}         ||
> > > > >
> > > > >= Cordova JS =
> > > > >
> > > > >The version of the JS is stamped at the top of the built .js file
by
> > > > >grunt.
> > > > >
> > > > >Currently, the version is derived using `git describe` and so is
> based
> > > off
> > > > >of the closest git tag in the history. This works well for releases,
> > but
> > > > >isn't great for dev builds since there are no tags made on master.
> > > > >
> > > > >'''Proposal:'''
> > > > > 1. Follow platform versioning scheme and store it in a constant
> > within
> > > > >Gruntfile.js.
> > > > > 1. When in built in the context of a git repo, and not at a tagged
> > > > >commit,
> > > > >append the git hash.
> > > > > 1. When not in a git repo or at a tagged commit, don't try and
> > append a
> > > > >hash.
> > > > >
> > > > >= Core Plugins =
> > > > >
> > > > >Current state is that we have master & dev branches. This is because
> > > > >plugman pulls from master by default, so it must remain stable.
> > > > >
> > > > >Once plugman-registry is launched, it should be used instead
> > > > >
> > > > >'''Proposal:'''
> > > > > 1. Stick with dev / master branches
> > > > > 1. Releases involve:
> > > > >    a. Update plugin.xml's version to "3.1.0"
> > > > >    a. Merge dev -> master
> > > > >    a. Update plugin.xml's version again to say "3.2.0-dev"
> > > > >
> > > > >= Plugman & CLI =
> > > > >
> > > > >These tools are built as npm modules, and so use package.json &
> semver
> > > > >versioning.
> > > >
> > > >
> > >
> >
>

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