cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Post 3.0.0 Releases - Plugins
Date Mon, 19 Aug 2013 08:29:07 GMT
Okay, took me awhile to get this out, I should know better than to promise
to start a new threads on Friday afternoon. XD

Split from 'Releases in a 3.0 World'

RE: Pasted =>

> 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


I don't think that we should dictate what we expect the community to do
with their own plugins. Here's some alternative thoughts:

a) versioning is done however the developer of the plugin wants to do it,
for core plugins, because they are within our control and we ARE 'the
developer' we will use semver.
b) plugman needs to gain the ability to install any particular version of a
plugin, just like a plugin can depend on a specific version of another
plugin, we need to be able do this directly.
c) do not enforce the use of a dev branch, master should be considered a
work in progress, we have already had issues where 1 broken push to master
[1] broke the plugin for all platforms.
-  My personal expectation of a 'master' branch is that tests are passing,
but it is still the bleeding edge, and I should use it at my own risk.
-  If we want to suggest a tested latest version, in production, I think we
should use a tag or branch of 'latest-stable' or something similar.
- also, plugman should be aware of version via tags or branches, and not
blindly pull from master, this would likely be handled at plugin
registration time.  ( as in b above ) Then we can test a plugin's
integration with other plugins before pushing it live.

The rest of the initial proposal is about process, which I don't think we
govern for plugin developers.  We can certainly adopt something like this
for the core plugins, but I think we should let the process evolve, and not
pretend we know what will happen next.

I am not completely sold on the above, some of this is just me thinking out
loud, the main thing I worry is just that we may not have enough info to
fully define this ( at least the process stuff), and I think it definitely
needs more discussion, and even maybe some experimentation.






[1]
https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-network-information.git;a=commitdiff;h=2aec962575f830de49c103bce7122376e0fcb8cc;hp=96b0c5d2f61f977916441447f7ed787fa670771f



@purplecabbage
risingj.com

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