cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Releases in a 3.0 World
Date Wed, 04 Sep 2013 18:51:40 GMT
Responses inline. For all of them, I'll update the wiki to make things
clear.


On Tue, Sep 3, 2013 at 12:54 PM, Michal Mocny <mmocny@chromium.org> wrote:

> For Strategy page:
>
> RE: Weekly Releases -- do we skip a release if there is nothing significant
> to push, or do we release so long as there is at least one patch?
>
I'd say skip.



> RE: Cadence Releases -- "These releases include: platform repos,
> cordova-js, mobile-spec, cordova-docs, cordova-cli, cordova-plugman" --
> clarifying that "include" for the sem-ver projects means only packaging
> into a zip/tarball, not that we bump versions numbers during a cadence
> release?  Or do we bump sem-ver as well?
>

cordova-js, mobile-spec, cordova-docs, cordova-cli: Update their versions
to the current CadVer
plugman: Probably should be removed from this list.
platform-repos: semver bump if there were any changes since prev release.



> ======
>
> For plugin release page:
>   "# Edit version within plugin.xml based off of changes."   --- this means
> "deduce the semantic effect on version" right?  IE, is it a
> major/minor/point release?
>
Yes (will update wording)

>
> Generally, how do we prevent changes from sneaking in to core plugins
> during the time it takes release master to make the changes?  The release
> master has to commit back to Changelog.  Perhaps he/she makes that change
> directly on master, and we rebase that change back into dev after the
> release?  That way, we don't read from dev branch once a release process is
> started.
>
Hrm, how about instead of merging dev->master, we merge CHANGELOG.md commit
-> master.


>
> "For each plugin that had unreleased commits .. increment the micro"  --
> why?
>
So that the version on dev is greater than the version on master.


>
> TEST section -- suggest adding a not to the top of the guide so that you
> create mobile-spec BEFORE starting the release.  This way, you create a
> project with the old versions of plugins more easily.
>

Good idea.

>
> ======
>
> Generally these looks really good (haven't finished reading Cadence release
> doc yet, will comment on that soon).  However, while I love the code
> snippets for suggested commands, some of them look like they wouldn't work
> if you copy&paste them.  Perhaps we should go through the docs on the next
> release and make it clear which are verbatim commands and which are just
> documentation-with-code.
>
>
>
>
> On Tue, Sep 3, 2013 at 12:18 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
>
> > Finally finished updating the wiki's instructions to follow this
> proposal.
> >
> > Summary of changes:
> >
> > https://wiki.apache.org/cordova/VersioningAndReleaseStrategy
> >   - Explains our versioning strategy (SemVer vs CadVer)
> >
> > https://wiki.apache.org/cordova/CommitterWorkflow
> >   - Extracted Pull Requst Processing into its own page (
> > ProcessingPullRequests<
> > https://wiki.apache.org/cordova/ProcessingPullRequests>
> > )
> >   - Added a "Which Branch to Commit To" section
> >   - Minor tweaks to commit process:
> >     - Mention `git rebase origin/master -i`
> >     - Marked some steps as optional
> >     - Linked to post-review (rbtools) install page
> >     - Made it more explicit that you should test commits you patch in
> >
> > https://wiki.apache.org/cordova/StepsForPluginRelease
> >   - Process to go through to update core plugins
> >
> > https://wiki.apache.org/cordova/StepsForToolsRelease
> >   - Process to go through to update plugman / CLI
> >
> > https://wiki.apache.org/cordova/CuttingReleases
> >   - Made it clear that it applies to Cadence Releases
> >   - Expanded "What to test" section
> >   - Added releasing of CLI to the steps
> >   - Moved "Official Apache Releases" to the bottom
> >
> > To all steps release steps pages, I've added an "Update CHANGELOG.md"
> step.
> > iOS has done this forever, but I think all repos should do it.
> >
> > Would love if these pages could be read by all committers. Especially the
> > StepsForToolsRelease page, as I've never done a tools release (and so was
> > somewhat guessing).
> >
> > Another part I'm unsure of is where the mapping to platform repo versions
> > is within CLI.
> >
> > There are still some points to discuss, which I will send separate emails
> > about :)
> >
> >
> > On Sun, Aug 18, 2013 at 11:30 PM, Ian Clelland <iclelland@google.com>
> > wrote:
> >
> > > On Fri, Aug 16, 2013 at 5:41 PM, Andrew Grieve <agrieve@chromium.org>
> > > wrote:
> > >
> > > > After the discussion on the group hangout + some sleeping, I think
> > we're
> > > > ready for a proposal... So here it is!
> > > > - It does *not* propose any changes to our Deprecation policy. That's
> > for
> > > > another thread (which I'll get to on Monday if no one else does) :)
> > > > - It does not contain how we store version numbers. That's covered
> > here:
> > > > http://wiki.apache.org/cordova/StoringRepoVersionsDesign
> > > >
> > > > Once we get to a consensus, I'll transfer this to the wiki. Please
> > > review &
> > > > comment!
> > > >
> > > > There are two kinds of versions:
> > > > 1. "SemVer" (www.semver.org)
> > > >    - Used by platforms, plugman, cli
> > > > 2. "CadVer" (just made that up :P "Cadence Version")
> > > >    - Used by cli, mobile-spec, cordova-js
> > > >
> > > >
> > > I like this, as it separates the fast-moving, feature-based semantic
> > > version of any given component from the API level, and interoperability
> > > promises, of the "Cadence Version".
> > >
> > > What, then, is the granularity of the Cadence Version intended to be?
> Is
> > is
> > > the "3" in Cordova 3.0, and will stay at 3 until it hits 4 next year?
> > (Or,
> > > just as descriptively, we can say that it is at "Cordova Fancy-Pants"
> > now,
> > > and eventually progress to "Cordova Enraged-Wombat")
> > >
> > > Or is it going to have major and minor components as well, and advance
> > > roughly monthly, as before?
> > >
> > >
> > > > There are two kinds of releases:
> > > > 1. Patch releases
> > > >    - Pretty much any repo can release a patch release to fix bugs at
> > any
> > > > time (but should have good reason)
> > > > 2. Cadence releases
> > > >    - These follow the 10 releases per year, as enumerated on:
> > > > http://wiki.apache.org/cordova/RoadmapProjects
> > > >
> > > > cordova-plugins:
> > > >  - Commit only to the `dev` branch
> > > >  - Use semver for them.
> > > >    - If the version on master is "3.0.0", then the version on dev
> will
> > > > start at "3.0.1-dev".
> > > >    - If any commit goes in that add a feature, then change the
> version
> > on
> > > > dev to "3.1.0-dev"
> > > >    - If any commit goes in that makes an non-backwards-compatible
> > change,
> > > > then change the version on dev to "4.0.0-dev"
> > > >  - Release plugins at most once a week (Thursdays?)
> > > >    - This *does* mean that a change that goes in Wednesday could end
> up
> > > > being released the next day.
> > > >  - Release plugins all at the same time so that we can blog the
> release
> > > > notes.
> > > >  - Release process:
> > > >    1. Create a JIRA issue to track the status of the release.
> > > >      a. Comments should be added to this bug after each top-level
> step
> > > > below is taken
> > > >    2. For each plugin that has unreleased commits on their `dev`
> > branch:
> > > >      a. Update its CHANGELOG file with a prettified version of "git
> > log"
> > > >      b. Update its plugin.xml version by removing the "-dev" suffix
> > > >      c. Merge dev -> master (without pushing)
> > > >      d. Update its plugin.xml version by incrementing the micro and
> > > adding
> > > > "-dev" (as described above)
> > > >    3. Combine all plugin changelogs into a Release announcement blog
> > post
> > > > on cordova-website.
> > > >      a. Steps for this exist in cordova-website's README.md
> > > >    4. Test
> > > >      a. Create mobilespec using the old versions of plugins
> > > >      b. Perform a "plugin upgrade" for plugins that have changes
> (right
> > > > now, this means doing a `plugin remove` followed by a `plugin add`
> > > >      c. Run through mobilespec, ensuring to do manual tests that
> relate
> > > to
> > > > changes in the changelog
> > > >    5. Push!
> > > >      a. Push all branches
> > > >      b. Push the blog post
> > > >
> > > > cordova-plugman:
> > > >   - Commit to master always
> > > >   - Release only when necessary.
> > > >   - Release process:
> > > >     1. For releases that increment the minor or major, email the dev
> > list
> > > > to let others know about your intent to release (include changelog)
> > > >        a) Wait for at least one +1
> > > >     2. Increment the version within package.json
> > > >     3. Update RELEASENOTES.md with the changes for this release
> > > >     4. Push to npmjs.org
> > > >        * In order to push, you must be given push access to the npm
> > > module.
> > > >        * To do so, ask one of the existing module maintainers (listed
> > > here:
> > > > https://npmjs.org/package/plugman)
> > > >     5. Post a release announcement on the cordova blog (for feature
> > > > releases only)
> > > >       a. Steps for this exist in cordova-website's README.md
> > > >       b. Not necessary for patch releases, but feature releases
> should
> > > > mention significant bugs fixed by previous patch releases.
> > > >
> > > > No JIRA: The process is light-weight enough that a JIRA issue isn't
> > > > necessary for tracking.
> > > >
> > > >
> > > > cordova-cli:
> > > >   - Commit to master, release from release branches (2.9.x, 3.0.x,
> etc)
> > > >   - Versioned using "$COROVA_VERSION-$CLI_VERSION"
> > > >     - E.g. 3.0.0-0.5.1
> > > >     - The first version component is the "cadence version", and has
> its
> > > > minor incremented whenever the platform repository that it lazy loads
> > by
> > > > default is changed
> > > >        - E.g. 3.0.0 uses cordova-blackberry@3.0.0, cordova-ios@3.0.0
> ,
> > > > cordova-android@3.0.0
> > > >        - E.g. 3.1.0 uses cordova-blackberry@3.1.0, cordova-ios@3.0.1
> ,
> > > > cordova-android@4.0.0
> > > >         - E.g. 3.2.0 uses cordova-blackberry@3.1.1,
> cordova-ios@3.1.0,
> > > > cordova-android@4.0.1
> > > >        - E.g. 3.2.1 uses cordova-blackberry@3.1.2, cordova-ios@3.1.0
> ,
> > > > cordova-android@4.0.1
> > > >   - The version number of cordova-cli will be the version number that
> > we
> > > > advertise on our website, blogs & docs
> > > >        - Platform version numbers will use semver, and not be
> > referenced
> > > >   - Release process for patch releases:
> > > >     1. cherry-pick commits from master -> latest release branch
> > > >     2. Increment package.json's micro version
> > > >     3. Update RELEASENOTES.md
> > > >     4. Push to npmjs.org
> > > >        * In order to push, you must be given push access to the npm
> > > module.
> > > >        * To do so, ask one of the existing module maintainers (listed
> > > here:
> > > > https://npmjs.org/package/cordova)
> > > >   - Release process for minor version
> > > >     - Same as patch release, and in addition:
> > > >       1. Email the dev list to let others know about your intent to
> > > release
> > > > (include changelog)
> > > >          a. Wait for at least one +1
> > > >       2. Post a release announcement on the cordova blog (for feature
> > > > releases only)
> > > >         a. Steps for this exist in cordova-website's README.md
> > > >         b. Not necessary for patch releases, but feature releases
> > should
> > > > mention significant bugs fixed by previous patch releases.
> > > >   - Release process for major version:
> > > >     - Refer to platform release process.
> > > >
> > > > cordova platforms, mobile-spec, cordova-js:
> > > >   - Same as before (as documented on
> > > > http://wiki.apache.org/cordova/CuttingReleases)
> > > >   - Except:
> > > >     - Platforms versions to use semver. This *does* mean that they
> will
> > > > diverge from each other.
> > > >     - cordova-js and cordova-mobile-spec to use the "cadence version"
> > > > (first part of cordova-cli's version)
> > > >     - No longer update cordova-app-template
> > > >     - Blog post will include changelog for all changes since previous
> > > > platforms release.
> > > >     - JIRA issue should have a comment that lists the platform
> versions
> > > > that are referenced by the cadence version.
> > > >
> > > > JIRA workflow:
> > > >   - When issues are closed, the "fixed version" should be set to the
> > > > cadence version.
> > > >
> > > >
> > > > Andrew
> > > >
> > > >
> > > > On Thu, Aug 8, 2013 at 4:18 PM, Andrew Grieve <agrieve@chromium.org>
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Aug 7, 2013 at 8:49 PM, Michael Brooks <
> > > michael@michaelbrooks.ca
> > > > >wrote:
> > > > >
> > > > >> >
> > > > >> > Plugins and CLI tools I think we should just ship continuously.
> > The
> > > > >>
> > > > > Why do you think these should be shipped continuously instead of
> on a
> > > > > regular cadence? Note that I think they should be as well, but I'm
> > > trying
> > > > > to figure out why the tools & plugins are different from the
> > platforms.
> > > > >
> > > > >
> > > > >> > only question that remains in the 'how' of that is versioning.
> > Mike
> > > > >> > Brookes has advocated semver schema here wherein we version
> > > platforms
> > > > >> > separately from the tools using a compound version number.
An
> > > example
> > > > >> > of this might be 3.0.0-0.14.3 wherein 3.0.0 represents our
> > platforms
> > > > >> > while 0.14.3 represents the CLI tool itself.
> > > > >>
> > > > >>
> > > > >> I only advocate semver for node modules and you can expect that
> I'll
> > > be
> > > > >> pushing this on cordova-cli soon. :)
> > > > >>
> > > > >> Node modules use semver. Regardless of whether it's effective
or
> > not,
> > > > it's
> > > > >> what the community uses and as developers we should attempt to
> > respect
> > > > and
> > > > >> adhere to it.
> > > > >> However, Cordova uses a different type of versioning scheme.
> > > > >>
> > > > >> The CLI tool needs to represent both of these versioning schemes.
> > > > >>
> > > > >> - The Cordova version is most important, because it describe
what
> > > > version
> > > > >> of Cordova the CLI uses.
> > > > >> - The node module version is important to modules consuming
> > > cordova-cli.
> > > > >> You have no idea how frustrating cordova-cli's current versioning
> is
> > > wrt
> > > > >> to
> > > > >> the phonegap-cli.
> > > > >>
> > > > >> This is why a version such as 3.0.0-0.10.4 works extremely well.
> > It's
> > > > >> distributing version 3.0.0 of Cordova. The node module itself
is
> > > version
> > > > >> 0.10.4. It's also semantically valid in semver, so it's compatible
> > > with
> > > > >> npm.
> > > > >>
> > > > >> Michael
> > > > >>
> > > > >>
> > > > >> On Wed, Aug 7, 2013 at 1:27 PM, Andrew Grieve <
> agrieve@chromium.org
> > >
> > > > >> wrote:
> > > > >>
> > > > >> > On Wed, Aug 7, 2013 at 12:49 PM, Brian LeRoux <b@brian.io>
> wrote:
> > > > >> >
> > > > >> > > I think keeping the cadence on the core platforms makes
sense.
> > > That
> > > > is
> > > > >> > > where the bulk of logic lives, it is susceptible to
3rd party
> > > issues
> > > > >> > > like new iDEs and SDKs, and having that regular cadence
in
> > > lockstep
> > > > >> > > makes issue tracking easier to discuss with the community.
> > > > >>
> > > > > I agree that keeping the number of different version numbers to a
> > > minimum
> > > > > makes things easier to track.
> > > > > I don't really follow your logic about IDEs and SDKs... This would
> be
> > > an
> > > > > argument to *not* synchronize releases I think, since
> > iOS/Android/WP/BB
> > > > do
> > > > > not synchronize their SDK releases :P
> > > > > I don't think we can apply the cadence argument to platforms, but
> not
> > > to
> > > > > tools & plugins. Why would platforms be different in this respect?
> > > > >
> > > > >  > >
> > > > >> > > Plugins and CLI tools I think we should just ship
> continuously.
> > > The
> > > > >> > > only question that remains in the 'how' of that is
versioning.
> > > Mike
> > > > >> > > Brookes has advocated semver schema here wherein we
version
> > > > platforms
> > > > >> > > separately from the tools using a compound version
number. An
> > > > example
> > > > >> > > of this might be 3.0.0-0.14.3 wherein 3.0.0 represents
our
> > > platforms
> > > > >> > > while 0.14.3 represents the CLI tool itself.
> > > > >> > >
> > > > >> > > I am not a fan of semver as that it is almost wholly
> conceptual
> > > and
> > > > >> > > thusly non-enforcable. It is a nice framework for reasoning
> but
> > > ppl
> > > > >> > > ignore half of the rules devaluing its promise. Also,
it was
> > > > conceived
> > > > >> > > originally as a solution for globally installed packages
which
> > > isn't
> > > > >> > > really an issue in modern situations. That said, having
a
> > > versioning
> > > > >> > > scheme that exists, is well documented, and generally
> understood
> > > are
> > > > >> > > all positives for me. It would mean our deprec policy
could
> push
> > > the
> > > > >> > > version numbers up quickly (which is fine).
> > > > >> > >
> > > > >> > > It is important to remember the reason for versioning,
for our
> > > case,
> > > > >> > > is issue tracking and resolution but as our ecosystem
grows it
> > > will
> > > > >> > > also play a very important role in dependency management.
> > > Especially
> > > > >> > > between plugins. More discreet versions: the better.
> > > > >>
> > > > > With the latest <engine> tag work being done (
> > > > > https://issues.apache.org/jira/browse/CB-4490), platforms as well
> as
> > > > > plugins will be checked using semver. These checks will likely work
> > > > better
> > > > > if we try and follow semver. AFAICT, we mostly do already follow
> it,
> > > with
> > > > > the exception of our deprecation policy.
> > > > >
> > > > >
> > > > >> > >
> > > > >> > > (Andrew I think you should start a separate thread
about
> killing
> > > off
> > > > >> > > cordova-js and moving into platforms for loading now
that we
> > have
> > > > >> > > mostly removed the plugins. I am very much in favor!)
> > > > >> > >
> > > > >> > Yeah, I regretted this almost immediately. Since this thread
is
> > > > >> focusing on
> > > > >> > the platforms, I'll do just that!
> > > > >> >
> > > > >> >
> > > > >> > >
> > > > >> > >
> > > > >> > > On Tue, Aug 6, 2013 at 1:43 PM, Andrew Grieve <
> > > agrieve@chromium.org
> > > > >
> > > > >> > > wrote:
> > > > >> > > > Want to have this as a discussion starter.
> > > > >> > > >
> > > > >> > > > We've previously established that:
> > > > >> > > > 1. Releases for plugman & CLI will not be
tied to platform
> > > > releases
> > > > >> > > > 2. Releases to plugins will not be tied to platform
releases
> > > > >> > > >
> > > > >> > > > That's not to say we shouldn't sometime co-ordinate
them
> with
> > > > >> platform
> > > > >> > > > releases, but I think there would need to be a
compelling
> > reason
> > > > to
> > > > >> > > couple
> > > > >> > > > them.
> > > > >> > > >
> > > > >> > > > I'm wondering if it makes sense to not tie platform
releases
> > > > >> together
> > > > >> > > > either? E.g. Allow an update to cordova-ios separately
from
> > > > >> > > > cordova-blackberry10.
> > > > >> > > >
> > > > >> > > > Possible Advantages:
> > > > >> > > >   - Releases will (hopefully) occur more frequently.
Don't
> > need
> > > to
> > > > >> wait
> > > > >> > > for
> > > > >> > > > synchronization with other platforms to do a release.
> > > > >> > > >
> > > > >> > > > Possible Disadvantages:
> > > > >> > > >   - Might make for too many releases & spam
our users with
> > > release
> > > > >> > notes
> > > > >> > > > too often
> > > > >> > > >   - Might make us lazy and release platforms too
> infrequently
> > > > >> > > >   - Might make version numbers for platforms not
correspond
> > > > >> date-wise
> > > > >> > > with
> > > > >> > > > version numbers of other platforms (e.g. 3.1 ios
!= 3.1
> > android)
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > Other considerations:
> > > > >> > > >   cordova-js is a common piece here. Perhaps that
could be
> > > pulled
> > > > >> out
> > > > >> > as
> > > > >> > > > well?
> > > > >> > > >
> > > > >> > > > Option 1: Bundle the exec bridge, platform bootstrap
&
> plugin
> > > > loader
> > > > >> > with
> > > > >> > > > the platform, and have the rest available as a
plugin.
> > > > >> > > > Option 2: Bundle exec bridge + platform bootstrap
with the
> > > > platform,
> > > > >> > > bundle
> > > > >> > > > the plugin loader with plugman, put the rest in
a plugin
> > > > >> > > >
> > > > >> > > > For reference, the only non-exec-bridge / start-up
code I
> can
> > > see
> > > > >> is:
> > > > >> > > > ./cordova.js   <--- hooks addEventListener
+ has exec bridge
> > > logic
> > > > >> > > > ./common/argscheck.js   <--- strictly a helper
for plugins
> > > > >> > > > ./common/base64.js   <--- exec bridge depends
on this
> > > > >> > > > ./common/builder.js  <--- should be folded
into
> > modulemapper.js
> > > > >> > > > ./common/channel.js  <--- start-up code needs
this
> > > > >> > > > ./common/init.js  <--- start-up code
> > > > >> > > > ./common/modulemapper.js  <--- start-up code
> > > > >> > > > ./common/pluginloader.js  <--- loads plugins
on start-up
> > > > >> > > > ./common/urlutil.js   <--- recently added helper
for plugins
> > > > >> > > > ./common/utils.js   <--- mostly misc stuff
that may be
> mostly
> > > > >> unused?
> > > > >> > > >
> > > > >> > > > There's also:
> > > > >> > > > ./windows8/windows8/commandProxy.js
> > > > >> > > > which I assume is exec bridge releated.
> > > > >> > > >
> > > > >> > > > I think that argscheck & urlutil would be
well-suited as
> > > > stand-alone
> > > > >> > > > plugins that other plugins depend on.
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>

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