cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: tag 3.0.0rc1 on Monday the 15th
Date Mon, 15 Jul 2013 23:26:44 GMT
huzzah! great.

btw - im still learning to type with a baby in one arm :)

that command doesnt exist in coho.

./cordova-coho/coho repo-update -b 3.0.x -r REPOS

comes close, but wont change branch if there were no changes.


On Mon, Jul 15, 2013 at 7:15 PM, Steven Gill <stevengill97@gmail.com> wrote:

> Hey Andrew,
>
> I posted in here before reading the getting organized for 3.0 thread. I
> retract my statement that every plugin needs issues and agree with plugins
> being tested by platform maintainers before they tag their respective
> platforms. I created one issue to tag all of the plugins once platforms are
> tagged.
>
>
> On Mon, Jul 15, 2013 at 4:12 PM, Joe Bowser <bowserj@gmail.com> wrote:
>
> > So, since we're stuck with coho if we want to get this done this week,
> > how do you get coho to check out a branch of all the plugins?
> >
> > On Mon, Jul 15, 2013 at 4:10 PM, Andrew Grieve <agrieve@chromium.org>
> > wrote:
> > > On Mon, Jul 15, 2013 at 5:22 PM, Steven Gill <stevengill97@gmail.com>
> > wrote:
> > >
> > >> We will need to add issues for tagging plugins.
> > >
> > > What's your reasoning?
> > >
> > >
> > >
> > >> I can create the issue and
> > >> tag the plugins. I figure for now, plugins will use same tagging
> > process as
> > >> other repos.
> > >>
> > > And that process is?
> > >
> > > For the RC - it's trivial to create release branches and an RC tag.
> coho
> > > can do it in bulk. The main question is what criteria should we use to
> > > determine whether a plugin is ready for tagging? For an RC, we could
> just
> > > tag with whatever's there , but then it's not really adding any meaning
> > on
> > > top of the release branch existing. I think the thing that separates
> the
> > > release branch from the tag is some testing.
> > >
> > >
> > >>
> > >>
> > >> On Mon, Jul 15, 2013 at 12:02 PM, Filip Maj <fil@adobe.com> wrote:
> > >>
> > >> > Created the issues: https://issues.apache.org/jira/browse/CB-4208
> > >> >
> > >> > On 7/15/13 11:56 AM, "Joe Bowser" <bowserj@gmail.com> wrote:
> > >> >
> > >> > >So, for tagging today, can we get the issues setup and the JS
> tagged
> > >> > >at least? We can somehow muddle through this RC1.
> > >> > >
> > >> > >On Mon, Jul 15, 2013 at 9:48 AM, Brian LeRoux <b@brian.io>
wrote:
> > >> > >> I'd say we could consider the core plugins as build ephemera
not
> > >> > >> unlike docs or automations. Really cordova-cli is the main
point
> of
> > >> > >> interaction between us and our developer community.
> > >> > >>
> > >> > >>
> > >> > >> On Mon, Jul 15, 2013 at 9:03 AM, Andrew Grieve <
> > agrieve@chromium.org>
> > >> > >>wrote:
> > >> > >>> The Apache Way was a part of what I was thinking as well.
> > >> > >>>
> > >> > >>> Also - it occurs to me that we'll have to change our
voting
> system
> > >> > >>>when it
> > >> > >>> comes to plugins since each plugin repo should have a
+1 from
> each
> > >> > >>>platform
> > >> > >>> maintainer, and can be tagged only once.
> > >> > >>>
> > >> > >>>
> > >> > >>> On Fri, Jul 12, 2013 at 12:53 PM, Joe Bowser <bowserj@gmail.com
> >
> > >> > wrote:
> > >> > >>>
> > >> > >>>> Don't we have to release a zip on an Apache server
because of
> > "The
> > >> > >>>> Apache Way"?  That's why I thought we had to release
artifacts,
> > not
> > >> > >>>> for people, but for process.
> > >> > >>>>
> > >> > >>>> On Fri, Jul 12, 2013 at 9:31 AM, Brian LeRoux <b@brian.io>
> > wrote:
> > >> > >>>> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message