cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: Getting Organized for 3.0
Date Tue, 16 Jul 2013 00:09:16 GMT
+1 Fil

On Monday, July 15, 2013, Steven Gill wrote:

> Agree with Fil. We should probably stick to the apache way for now and
> release source for all of the repos.
>
> Another question. Are we branching plugins as well? Shaz made a good point
> that since we aren't developing on 3.0.x branches for plugins, might as
> well just stick to only tagging plugins and not bother with branching.
>
> Thoughts?
>
> P.S. I am going to create the branches for all of the other platforms now
> (using coho)
>
>
>
>
> On Mon, Jul 15, 2013 at 5:00 PM, Filip Maj <fil@adobe.com> wrote:
>
> > While I would personally like to see that approach, in the spirit of the
> > "apache way", I think we should still be packaging a release with a
> > specific commit from all relevant project repos (whether they include the
> > plugin repos or not is up for debate but I am fairly ambivalent on that
> > topic). This satisfies the apache requirement of having a release archive
> > containing everything you need to get started, and doesn't block us from
> > our more "online" way of loading particular versions of
> frameworks/plugins
> > into your own application shell.
> >
> > On 7/15/13 2:32 PM, "Brian LeRoux" <b@brian.io> wrote:
> >
> > >I'd like to add to that the release would probably be best served as
> > >just shipping cordova-cli instead of all the build artifacts that
> > >realize the cordova-cli interface.
> > >
> > >Thoughts?
> > >
> > >
> > >
> > >On Mon, Jul 15, 2013 at 1:58 PM, Brian LeRoux <b@brian.io> wrote:
> > >> That sounds better to me. Steve is going to verify and tag the plugin
> > >> repos to 3.0.0 today. The tacit agreement we've been discussing was
> > >> that plugins would then only be updated tag wise when they themselves
> > >> are updated.
> > >>
> > >>
> > >> On Mon, Jul 15, 2013 at 1:41 PM, Andrew Grieve <agrieve@chromium.org>
> > >>wrote:
> > >>> On Mon, Jul 15, 2013 at 3:48 PM, Joe Bowser <bowserj@gmail.com>
> wrote:
> > >>>
> > >>>> On Mon, Jul 15, 2013 at 12:34 PM, Andrew Grieve <
> agrieve@chromium.org
> > >
> > >>>> wrote:
> > >>>> > We really need to have a plan for this release, so here goes:
> > >>>> >
> > >>>> > 1. How to tag plugins:
> > >>>> > - Voting via tagging won't work here since each plugin has
> multiple
> > >>>> > platforms.
> > >>>> > - Let's create a sub-task for each plugin, and have each platform
> > >>>>add a
> > >>>> > comment to the sub-task when they have "signed off" on it.
Once
> all
> > >>>> > platforms have been tested / signed-off, then it can be tagged.
> > >>>>
> > >>>> Sounds good.
> > >>>>
> > >>>
> > >>> I no longer think this sounds good :P. Talked it through a bit with
> > >>>Ian /
> > >>> David / Max. Let's continue on with the existing JIRA issue, which
> has
> > >>>a
> > >>> "Tag $PLATFORM" entry.
> > >>> As a part of tagging your platform, you are signing off on having
> > >>>tested
> > >>> all of the plugins on your platform (aka, the same testing process
> > >>>that we
> > >>> had before).
> > >>> Once all of the platforms are tagged, we can use coho to bulk tag all
> > >>>of
> > >>> the plugin repos.
> > >>>
> > >>>
> > >>>>
> > >>>> >
> > >>>> > 2. With this many repos, it's not easy getting them all back
to
> the
> > >>>> correct
> > >>>> > state / tag that they are supposed to be in for a release.
For
> this
> > >>>> reason,
> > >>>> > I think the .zip to apache servers *should* contain a snapshot
of
> > >>>>all
> > >>>> > platforms & plugins. This way it's easy to get a "3.0"
snapshot
> for
> > >>>>the
> > >>>> > forever future.
> > >>>>
> > >>>> I don't think we'll get agreement on this, but I have no feelings
> > >>>> either way.  As long as we're following the Apache Way, it sounds
> > >>>> good!
> > >>>>
> > >>>> >
> > >>>> > 3. Tagging / voting on platform repos. isn't that meaningful
until
> > >>>> plu

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