royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlosrov...@apache.org>
Subject Re: [Discussion] Package change names (was Re: 0.9.3 Release)
Date Tue, 29 May 2018 14:34:34 GMT
Hi

2018-05-29 16:00 GMT+02:00 Harbs <harbs.lists@gmail.com>:
>
>
> 1. How do we define what is “Core"?
>

*Core*: This classes are needed to build a Royale

Application. All pieces here are required. No CSS is present here

to wire any concrete relationship between pieces, as well avoiding

possible inclussions of CSS rules and/or bugs in a final App.


> 2. Should package names match the project names?
>

Normaly this is true always. Don't recall libraries with mixed package
names.
Some exceptions: Network has "net", but this is normal for less verbosity.


> 3. Do we care to try and make package names shorter (i..e limit the level
> of folders)?
>

Yes, if we can, but in the case os beads, since we'll be using mostly on
mxml, we put shorter class name over package levels. Even on AS3 in this
case is better a longer import than multiple longer class names use.


> 4. What are the advantages and disadvantages of making Basic a dependency
> for other component sets?
>

I think this is mostly explained here, and a image use to be better than
thousand words, but the image mix graphs and explanations:
https://snag.gy/DbH4iG.jpg


> 5. A question which might follow the ones above are whether we should add
> a new package. I’d rather wait to discuss this until we have some clarity
> on the ones above.
>

mmm...you mean to say "package" or new "library" (maybe you refer to
"Foundation" here)


>
> Can you think of any other questions we should be asking ourselves?
>

Not for now.

Thanks

Carlos



>
> Thanks,
> Harbs
>
> > On May 29, 2018, at 4:41 PM, Carlos Rovira <carlosrovira@apache.org>
> wrote:
> >
> > Hi,
> >
> > completely.
> >
> > two things:
> >
> > 1. I propose in the new Discussion thread to make that work myself, but
> we
> > can do together. I think the best way is to rename and move things in
> > chunks so we make this in various steps, testing builds not break, and so
> > on....this will take some days to reach a good shape.
> > 2. I already said my work was totally incomplete. But as we need this
> > discussion I didn't do more but fixing build.
> >
> >
> > 2018-05-29 15:13 GMT+02:00 Harbs <harbs.lists@gmail.com>:
> >>
> >>> First, the hopefully easy things we can agree on:
> >>> -I have no objection to dropping "Bead" off of bead class names
> >>> -I have no objection to moving all views into a view subfolder as long
> >> as nobody else is concerned about the size and performance issues.
> >>> -I have no objection to moving classes in Basic that are
> >> org.apache.royale.html to org.apache.royale.basic.
> >>> -I have no objection to doing a massive rename and long as it isn't me
> >> doing the work.
> >>> -Whatever is in Core and Basic now or before Carlos's started moving
> >> things around is not perfect.
> >>
> >> I agree with this completely. Carlos, do you agree as well? (I would be
> >> willing to help out with a rename, but I want to make sure it doesn't
> cause
> >> too much disruption.
> >>
> >> Thanks,
> >> Harbs
> >>
> >>> On May 23, 2018, at 12:43 AM, Alex Harui <aharui@adobe.com.INVALID>
> >> wrote:
> >>>
> >>> Hi Carlos,
> >>>
> >>> I guess I don't understand why separating beads from TLCs is better.
> >> How will that make things better for users or other component set
> >> developers?  That would effectively double the number of SWCs and each
> TLC
> >> SWC will need its bead SWC.  That doesn't sound like a good thing to me,
> >> but if that's what other folks want to do, that's fine with me.
> >>>
> >>> I was just looking through the classes in Jewel.  It looks like JeweL
> >> doesn't have a DataGrid yet..  When it does, I would think you will
> want to
> >> use the DataGridModel from Express as it handles both Arrays and
> >> ICollectionViews.  We will probably create a similar model bead that
> takes
> >> both ICollectionViews and Arrays for Lists and put that in Express as
> >> well.  Then we might decide that is better for Jewel to use that model
> >> instead.  Or maybe we'll decide to create a JewelExpress set that has
> those
> >> more general models that don't require as much configuration.  Anyway, I
> >> hope you agree that at some point, these more general models will be
> used
> >> by Express and some flavor of Jewel.  I don't think this general model
> >> should go in Core, or Basic (or some new category called Foundation).
> And
> >> at that point, Jewel or JewelExpress is going to re-use that code in
> >> Express.
> >>>
> >>> Component sets are encouraged to re-use existing code from any other
> SWC
> >> since I think we've agreed that re-use is important.
> >>>
> >>> My 2 cents,
> >>> -Alex
> >>>
> >>> On 5/21/18, 11:16 AM, "carlos.rovira@gmail.com <mailto:
> >> carlos.rovira@gmail.com> on behalf of Carlos Rovira" <
> >> carlos.rovira@gmail.com <mailto:carlos.rovira@gmail.com> on behalf of
> >> carlosrovira@apache.org <mailto:carlosrovira@apache.org>> wrote:
> >>>
> >>>   Hi Alex
> >>>
> >>>   what do you think about separating the part in Basic that is
> >> inherently the
> >>>   same as in Jewel (Button, CheckBox, TextInput, List, ...) along with
> >> CSS
> >>>   that wire the beads for Basic UI set, and left the fundamental
> >> building
> >>>   blocks as something that is not Core but can be reused by Basic and
> >> Jewel
> >>>   (Let's call this "Foundation" Lib, I even like this name for this
> >> library).
> >>>
> >>>   I mean that having "Foundation" lib and "Basic" lib, will be more
> >> clear,
> >>>   since we can expect what is in Basic will be never reused to build
> >> other UI
> >>>   Sets (MDL, or others can still hang from there or if someone wants to
> >> take
> >>>   the time refactor it).
> >>>
> >>>   Foundation will not have any CSS wiring beads. We can return classes
> >> from
> >>>   Core to Foundation.
> >>>
> >>>   Basic will have its own CSS wiring beads, the same for Jewel. Both
> >> will
> >>>   requiere Core and Foundation.
> >>>
> >>>   I assume this will make all of us happy.
> >>>
> >>>   We can as well do the package name changes to ensure consistency
> >> along all
> >>>   code and libraries.
> >>>
> >>>   Let me know what do you think
> >>>
> >>>   thanks
> >>>
> >>>   Carlos
> >>>
> >>>
> >>>   2018-05-21 19:38 GMT+02:00 Alex Harui <aharui@adobe.com.invalid>:
> >>>
> >>>> I understand this isn't the latest post on this thread, but it is the
> >>>> easiest one for me to reply to:
> >>>>
> >>>> First, the hopefully easy things we can agree on:
> >>>> -I have no objection to dropping "Bead" off of bead class names
> >>>> -I have no objection to moving all views into a view subfolder as long
> >> as
> >>>> nobody else is concerned about the size and performance issues.
> >>>> -I have no objection to moving classes in Basic that are
> >>>> org.apache.royale.html to org.apache.royale.basic.
> >>>> -I have no objection to doing a massive rename and long as it isn't
me
> >>>> doing the work.
> >>>> -Whatever is in Core and Basic now or before Carlos's started moving
> >>>> things around is not perfect.
> >>>>
> >>>> Now for the less easy.  Regarding Core vs Basic, I see it this way:
> >> Basic
> >>>> is the simplest implementation of the constructs/concepts in Royale.
> >> It is
> >>>> intended to be extended and enhanced by other component sets via our
> >> PAYG
> >>>> principles.  Core is intended to identify the constructs/concepts and
> >> their
> >>>> fundamental contracts.
> >>>>
> >>>> Think of it this way:  When you open any class in Royale, you will
> want
> >> to
> >>>> know what kind of class it is.  It is a TLC, a Bead?  And what kind
of
> >> TLC
> >>>> or Bead?  Is it  View, Model, Controller?  An ItemRenderer?  These are
> >> the
> >>>> categories of classes we had, even in Flex.  I've probably left out
a
> >> few
> >>>> categories.  It is the interfaces for these categories that go in
> Core.
> >>>> And maybe some classes we think are universal implementations of those
> >>>> categories.  And some beads that are component set agnostic, like
> >>>> BrowserResizeHandler, although we could move those to another SWC and
> >> say
> >>>> that Core should not have any MXML components except maybe State.
> >>>>
> >>>> After any rename/refactor we decide on, Basic should still have some
> >>>> interfaces because those interfaces describe the contract required for
> >> the
> >>>> simplest implementation.  I get that it can be a fine line between
> >>>> "fundamental" and "simplest", but where many classes that were in
> Basic
> >> get
> >>>> away from "fundamental" is mainly around Containers.  The way we
> handle
> >>>> Containers in Basic really seems like an opinion instead of a
> universal,
> >>>> "everyone must implement Containers this way" sort of thing.  So it
> does
> >>>> not seem right that lots of Container-related things were moved to
> Core.
> >>>>
> >>>> I thought we had agreement on the Terminology and Concepts thread that
> >>>> re-usable pieces would be organized into multiple SWCs like Apache or
> >> AS3
> >>>> Commons.  Any component set designer gets to choose what SWCs to
> borrow
> >>>> from.  The emulation SWCs may borrow from Express because they want
to
> >>>> re-use multi-purpose beads and aren't interested in the smallest,
> >> fastest,
> >>>> implementation.   Assuming we fix any issues with accidentally
> dragging
> >> in
> >>>> classes that aren't used, if you can re-use code from some other group
> >> of
> >>>> classes in another SWC, just do it.  But do it because you "want to".
> >>>> There is no "need to".  The implementers should "want" to re-use code
> >> when
> >>>> possible.
> >>>>
> >>>> In the end, many component sets will re-use Basic beads.  Maybe even
> >>>> transitively because they re-use Express which re-uses Basic.  That
> >> should
> >>>> be ok.  That doesn't make it Core.  It just that lots of component
> sets
> >>>> will start from simple implementations and add more complex
> >> functionality.
> >>>> The goal is to minimize code size and maximize performance by re-using
> >>>> code.  And as I thought we had agreed upon in Terminology and
> Concepts,
> >> we
> >>>> should not be afraid to re-use code.  We are asking our users to do
> >> exactly
> >>>> the same.  We must create testing infrastructure and have review
> periods
> >>>> and other processes so we don't break downstream component sets or our
> >>>> users applications.
> >>>>
> >>>> One related tidbit:  IMO, the way folks will know what beads work with
> >>>> what components will be done by identifying what interfaces the beads
> >>>> implement, but also, I expected that we would use ASDoc as well.  If
> you
> >>>> rummage through the source, you'll see that I annotated a few classes
> >> with
> >>>> @viewbead and @toplevel.  We could add more.  And because our ASDoc
is
> >> an
> >>>> app, we can then apply smarter filtering that help folks narrow down
> >> what
> >>>> their choices are, similar to many of the online shopping filters I
> see.
> >>>>
> >>>> My 2 cents,
> >>>> -Alex
> >>>>
> >>>>
> >>>> On 5/21/18, 3:53 AM, "Harbs" <harbs.lists@gmail.com> wrote:
> >>>>
> >>>>   Thank you for this.
> >>>>
> >>>>   There’s two groups of files that were changed: Interfaces and and
> >>>> Classes.
> >>>>
> >>>>   In general, I would be more inclined to move interfaces than
> classes,
> >>>> but there are some things to consider:
> >>>>
> >>>>   1. There are still 17 interfaces in Basic. If the 5 that were moved
> >>>> belong in Core, what about the remaining 17?
> >>>>   2. I don’t think we’ve come to an agreement on what belongs in
Core
> >>>> and what belongs in Basic.
> >>>>   3. I’d like to some to an agreement on a package name pattern. What
> >>>> defines something belonging to a “core” path as opposed to an “html”
> >> path?
> >>>> Some classes are in supportClasses and some had that removed from the
> >> path.
> >>>> What’s the logic? etc.
> >>>>   4. How should different pieces (such as different bead types) be
> >>>> defined in paths? (I don’t think we’re completely consistent today.)
> >>>>
> >>>>   I think we are coming to a conclusion on the CSS issues that Jewel
> >>>> brought up. I think the CSS problems can be solved no matter whether
> we
> >>>> move things between packages and no matter wether we change package
> >> paths.
> >>>> I think the question on reorganization needs to be discussed on its
> own
> >>>> right. Do you agree with that?
> >>>>
> >>>>   First organization of packages:
> >>>>   To me, there are two primary questions related to Core vs. Basic:
> >>>>   1. What is the defining criteria for something to belong in Core as
> >>>> opposed to Basic?
> >>>>   2. Is there an issue with one component set (i.e. Jewel) to rely on
> >>>> another (i.e. Basic).
> >>>>
> >>>>   To be clear: I do believe that there is likely some reorganization
> >>>> appropriate, but I’m not clear on exactly what and how.
> >>>>
> >>>>   Depending on the answers to these questions, we can have a number
of
> >>>> different courses of action. We might keep things very similar to how
> >> they
> >>>> are. We might move things from Basic to Core. We might split Basic
> into
> >> two
> >>>> packages. Other options?
> >>>>
> >>>>   Regarding package paths: I don’t think there’s a single “right”
> >> answer
> >>>> to that, but we do need to agree on a pattern that we all stick to.
> >>>> Currently (even before any refactor) package paths feel like many are
> >>>> haphazard, and I often have difficulty guessing what the path is for
a
> >>>> specific class. I also sometimes have difficulty guessing which
> package
> >> a
> >>>> specific class belongs to.
> >>>>
> >>>>   These are the high-level questions I have.
> >>>>
> >>>>   Please allow me to focus on question #2. I find it easiest to
> discuss
> >>>> concrete examples, so I’m taking TextPrompt, but it’s just an example.
> >>>> Basic has a TextPromptBead. Jewel has TextPrompt. The code of the two
> >>>> classes are identical. I’m assuming TextPrompt was copied because
> >>>> TextPromptBead does not belong in Core (something I agree with), and
> you
> >>>> did not want Jewel to have a dependency on Basic. So my question is
> >>>> (assuming CSS and classes not used are not copied), what is wrong with
> >>>> Jewel using the TextPromptBead in Basic? To me the advantage of using
> >> the
> >>>> Basic bead is that there’s no code duplication and that helps from
a
> >>>> development perspective (i.e. only a single place to fix bugs) and
> from
> >> a
> >>>> perspective of code size in the resulting application (in case both
> >> classes
> >>>> are used somewhere).
> >>>>
> >>>>   Harbs
> >>>>
> >>>>> On May 21, 2018, at 11:29 AM, Carlos Rovira <carlosrovira@apache.org
> >
> >>>> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> as we talked I take the time to make a list of package name changes.
> >>>>> Finally 20 classes were changed from package.
> >>>>> Here's the list from 16c0dcd643974fe708fd67a3774ea6e35e879811 (in
> >>>> red the
> >>>>> changes to better following)
> >>>>>
> >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/
> >>>> core/MXMLBeadView.as
> >>>>>
> >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html
> >>>>> /MXMLBeadView.as
> >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/
> >>>> core/beads/views/ContainerView.as
> >>>>>        frameworks/projects/Basic/src/
> >>>> main/royale/org/apache/royale/html/beads/ContainerView.as.
> >>>>>            (1)
> >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/
> >>>> core/beads/views/DataContainerView.as
> >>>>>    frameworks/projects/Basic/src/main/royale/org/apache/royale/
> >>>> html
> >>>>> /beads/DataContainerView.as
> >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/
> >>>> core/beads/GroupView.as
> >>>>>
> >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html
> >>>>> /beads/GroupView.as
> >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/
> >>>> core/beads/IBackgroundBead.as
> >>>>>            frameworks/projects/Basic/src/
> >>>> main/royale/org/apache/royale/
> >>>>> html/beads/IBackgroundBead.as
> >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/
> >>>> core/beads/IBorderBead.as
> >>>>>
> >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html
> >>>>> /beads/IBorderBead.as
> >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/
> >>>> core/beads/IDropDownListView.as
> >>>>>          frameworks/projects/Basic/src/
> >>>> main/royale/org/apache/royale/html
> >>>>> /beads/IDropDownListView.as
> >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/
> >>>> core/IListView.as
> >>>>>
> >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/
> >>>> html/beads/IListView.as.
> >>>>>                 (2)
> >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/
> >>>> core/beads/ITextFieldView.as
> >>>>>             frameworks/projects/Basic/src/
> >>>> main/royale/org/apache/royale/
> >>>>> html/beads/ITextFieldView.as                (2)
> >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/
> >>>> core/beads/TextFieldViewBase.as
> >>>>>          frameworks/projects/Basic/src/
> >>>> main/royale/org/apache/royale/html/beads/TextFieldViewBase.as
> >>>>>          (2)
> >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/
> >>>> core/beads/layouts/LayoutChangeNotifier.as
> >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html
> >>>>> /beads/layouts/LayoutChangeNotifier.as
> >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/
> >>>> core/beads/models/ArraySelectionModel.as
> >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html
> >>>>> /beads/models/ArraySelectionModel.as
> >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/
> >>>> core/beads/models/ViewportModel.as
> >>>>>       frameworks/projects/Basic/src/main/royale/org/apache/royale/
> >>>> html
> >>>>> /beads/models/ViewportModel.as
> >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/
> >>>> core/supportClasses/Border.as
> >>>>>            frameworks/projects/Basic/src/
> >>>> main/royale/org/apache/royale/
> >>>>> html/supportClasses/Border.as
> >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/
> >>>> core/supportClasses/ContainerContentArea.as
> >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/
> >>>> html/supportClasses/ContainerContentArea.as.
> >>>>> (2)
> >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/
> >>>> core/supportClasses/DataGroup.as
> >>>>>         frameworks/projects/Basic/src/
> >>>> main/royale/org/apache/royale/html/supportClasses/DataGroup.as
> >>>>>
> >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/
> >>>> core/DataItemRenderer.as
> >>>>>
> >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html/
> >>>>> supportClasses/DataItemRenderer.as      (3)
> >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/
> >>>> core/MXMLItemRenderer.as
> >>>>>
> >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html/
> >>>>> supportClasses/MXMLItemRenderer.as
> >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/
> >>>> core/UIItemRendererBase.as
> >>>>>
> >>>>> frameworks/projects/Basic/src/main/royale/org/apache/royale/html/
> >>>>> supportClasses/UIItemRendererBase.as
> >>>>> frameworks/projects/Core/src/main/royale/org/apache/royale/
> >>>> core/supportClasses/Viewport.as
> >>>>>          frameworks/projects/Basic/src/
> >>>> main/royale/org/apache/royale/html
> >>>>> /supportClasses/Viewport.as
> >>>>>
> >>>>> Some comments:
> >>>>>
> >>>>> (1) "views" should follow the same package structure we have with
> >>>> other
> >>>>> beads 8"models", "controllers"...) to be consistent.
> >>>>> (2) should go to "core/beads/views" as well
> >>>>> (3) item renderers that should normaly be used by final users could
> >>>> go some
> >>>>> kind of "itemRenderers" package, while base item redeemer classes
> >>>> could go
> >>>>> again to supportClasses.
> >>>>>
> >>>>> As Harbs said, if we agree in the change of packages, we should
do
> >>>> this
> >>>>> well and perform some other changes that make all more consistent
> >>>> though
> >>>>> libraries.
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> Carlos
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2018-05-17 11:16 GMT+02:00 Harbs <harbs.lists@gmail.com>:
> >>>>>
> >>>>>> Definitely a plan.
> >>>>>>
> >>>>>> My guess is that if we agree on changing package paths, there
will
> >>>> likely
> >>>>>> be other classes that should be considered.
> >>>>>>
> >>>>>> My preference would be to have this discussion after we finish
the
> >>>> project
> >>>>>> refactor discussion because I think it’s going to be related
to the
> >>>> outcome
> >>>>>> of that.
> >>>>>>
> >>>>>> Either way, I don’t think discussion should hold up the 0.9.3
> >>>> release.
> >>>>>> We’re already past due for a release. We want to “release
early and
> >>>> release
> >>>>>> often”… ;-)
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Harbs
> >>>>>>
> >>>>>>> On May 17, 2018, at 12:07 PM, Carlos Rovira <
> >>>> carlosrovira@apache.org>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Ok,
> >>>>>>>
> >>>>>>> what if:
> >>>>>>>
> >>>>>>> * I take the time to generate a list of classes with package
name
> >>>> changes
> >>>>>>> * Make a thread with the list to expose it
> >>>>>>> * Let's see from there if people can live with it (We'll
call
> >>>> people to
> >>>>>>> express about this changes and could see if are or not dramatic
to
> >>>> them)
> >>>>>>>
> >>>>>>> Sounds this like a plan?
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> 2018-05-17 10:58 GMT+02:00 Harbs <harbs.lists@gmail.com>:
> >>>>>>>
> >>>>>>>> Sure. Same here.
> >>>>>>>>
> >>>>>>>> But things are much more stable now. As we move closer
to “1.0”,
> >>>> I think
> >>>>>>>> we should be more careful about breaking changes and
documenting
> >>>> them
> >>>>>> when
> >>>>>>>> we decide they are necessary.
> >>>>>>>>
> >>>>>>>> As far as these specific changes go: We haven’t even
come to a
> >>>>>> conclusion
> >>>>>>>> on what (if any) package names should change yet, and
including
> >>>> those
> >>>>>>>> changes in a release is premature. If we do change package
names,
> >>>> I’m of
> >>>>>>>> the opinion that they should be decided on and all happen
at once
> >>>> to
> >>>>>>>> minimize impact on end-users.
> >>>>>>>>
> >>>>>>>> Does that help clarify things?
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>> Harbs
> >>>>>>>>
> >>>>>>>>> On May 17, 2018, at 11:49 AM, Justin Mclean <
> >>>> justin@classsoftware.com>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>>> We are at the point where people are using Royale
in
> >>>> production. While
> >>>>>>>> we can make breaking changes if they are warranted,
they should
> >>>> be kept
> >>>>>> to
> >>>>>>>> an absolute minimum and be carefully considered and
well
> >>>> documented if
> >>>>>> we
> >>>>>>>> do.
> >>>>>>>>>
> >>>>>>>>> There has been many previous breaking changes that
broke the
> >>>>>> application
> >>>>>>>> I was working on and some more major than this and cost
me a lot
> >>>> of
> >>>>>> time to
> >>>>>>>> fix. Until you make it version 1.0 I think people will
expect
> >>>> that some
> >>>>>>>> things may break with a new version. So why should this
be an
> >>>> exception
> >>>>>> to
> >>>>>>>> what has happened before? Saying that however, what
would be good
> >>>> to
> >>>>>> see is
> >>>>>>>> to provide guidance to what users need to change so
their app
> >>>> works with
> >>>>>>>> any changes / backward compatibility issues.
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>> Justin
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Carlos Rovira
> >>>>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%4
> 0adobe.com%
> >>>> 7Cbbb82e5ac5e34921bfe908d5bf09044e%7Cfa7b1b5a7b34438794aed2c178de
> >>>> cee1%7C0%7C0%7C636624967805497091&sdata=bdXVzZzjutIIwP9lWwAj
> osfP3JsQDt
> >>>> rkTp%2FcrETCLE4%3D&reserved=0
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Carlos Rovira
> >>>>> https://na01.safelinks.protection.outlook.com/?url=
> >>>> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%4
> 0adobe.com%
> >>>> 7Cbbb82e5ac5e34921bfe908d5bf09044e%7Cfa7b1b5a7b34438794aed2c178de
> >>>> cee1%7C0%7C0%7C636624967805497091&sdata=bdXVzZzjutIIwP9lWwAj
> osfP3JsQDt
> >>>> rkTp%2FcrETCLE4%3D&reserved=0
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>   --
> >>>   Carlos Rovira
> >>>   https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> >> 7C7fb72469866647e4264108d5bf46fcb5%7Cfa7b1b5a7b34438794aed2c178de
> >> cee1%7C0%7C0%7C636625234021648344&sdata=VP%2BrBk%2FGm2iYVLGKZBb5W%
> >> 2FSAPKFpD763hkpcXbTjPkA%3D&reserved=0 <https://na01.safelinks.
> >> protection.outlook.com/?url=http%3A%2F%2Fabout.me%
> >> 2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> >> 7C7fb72469866647e4264108d5bf46fcb5%7Cfa7b1b5a7b34438794aed2c178de
> >> cee1%7C0%7C0%7C636625234021648344&sdata=VP%2BrBk%2FGm2iYVLGKZBb5W%
> >> 2FSAPKFpD763hkpcXbTjPkA%3D&reserved=0>
> >>
> >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

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