Mailing-List: contact dev-help@manifoldcf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@manifoldcf.apache.org
Received-SPF: pass (athena.apache.org: domain of daddywri@gmail.com designates
 209.85.160.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <etPan.5436502a.5f5e7fd0.5084@Maynard.local>
References: 
 <CALUFAGDDENHD+h3gGZCAWQVuYen7bkBVm=nFhQSeKqFU=DE9qg@mail.gmail.com>
	<etPan.543647a4.1dbabf00.5084@Maynard.local>
	<CALUFAGAquwmKRf2si+BkpKWme+r_tPX3HQQvcrT2eQHFsAdUZQ@mail.gmail.com>
	<etPan.54364a44.1381823a.5084@Maynard.local>
	<CALUFAGAMg08kjjiwGdiyTX=p2PCM=+vX5xUFRvMEJ7gAFuVTHQ@mail.gmail.com>
	<etPan.5436502a.5f5e7fd0.5084@Maynard.local>
Date: Thu, 9 Oct 2014 07:53:43 -0400
Message-ID: 
 <CALUFAGDsxOLBwo1Cnb46JPEqcyezHR6i1k7pozy+QSqpKciWRQ@mail.gmail.com>
Subject: Re: Compatibility between 1.x and 2.0,
 and release plans going forward
From: Karl Wright <daddywri@gmail.com>
To: Rafa Haro <rharo@apache.org>
Cc: dev <dev@manifoldcf.apache.org>
Content-Type: multipart/alternative; boundary=20cf303ea6a69932380504fc151e

--20cf303ea6a69932380504fc151e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Rafa,

Writing UI support for a connector for ManifoldCF is, I agree, not
trivial.  There is a lot to remember, and a lot of ways to mess this up.
But I would like to point out the following:

-- You are definitely not limited name/value pairs in either configuration
or specification.  The underlying representation of both of these is a
hierarchical structure.  For configuration, though, we provide name-value
pair helper support, because it is commonly sufficient.

-- Over the years, there have been a lot of people with a lot of ideas
about how to save effort in implementing ManifoldCF connector UIs.  I
haven't yet seen one that is compelling.  We introduced Velocity as a way
of (at least) separating the HTML from the Java, but some people would
rather use just straight Java still.  The book does go into what I think
are current best practices (using Velocity).

-- For specifications, please bear in mind that one reason we separate
specifications from configuration is so that your specification UI can
query the repository for information, e.g. the names of sites etc.  So,
right away, you can see that a much higher level of customization is going
to be required for such UIs, and a one-size-fits-all model will not be
possible.

Any specific suggestions that you have are welcome.  I should expect such
suggestions to add support on top of our current API, rather than replacing
it, however.

Thanks,
Karl


On Thu, Oct 9, 2014 at 5:06 AM, Rafa Haro <rharo@apache.org> wrote:

> OK thanks Karl. That sounds much more better :-), because we will be
> focused only in one branch development at the end.
>
> I would like also to share with you some of concerns we have collected
> while working the last months with MCF. I will work on a comprehensive li=
st
> as soon as possible. Some of them will probably not fix with the current
> status and others would probably imply major changes not applicable right
> now. My aim with this is just to know your opinion, because we can be
> completely wrong of course.
>
> One of the main problem for us for example has been to deal with the UI
> when we wanted to include complex configuration stuff beyond key/value
> configuration fields. With the current approach, for example, we have spe=
nt
> too much time by debugging manually generated HTML and Javascript code. I
> see too much coupled the UI management with the business logic. Is there
> any idea for improving this for version 2.0?
>
> Thanks,
> Rafa
>
> En 9 de octubre de 2014 en 10:45:56, Karl Wright (daddywri@gmail.com)
> escrito:
>
> Hi Rafa,
>
> I committed the MCF 2.0 version of the connector you contributed, and the=
n
> pulled it up (using svn merge -c XXX) to the dev_1x branch. Currently,
> connectors developed with MCF 2.0 in mind will work on 1.7 or later.
>
> The procedure for _any_ development of new features and most fixes at thi=
s
> time is as follows:
>
> - code the feature/fix against trunk
> - pull up the feature/fix to the dev_1x branch, if appropriate
>
> Hope this help!
> Karl
>
>
> On Thu, Oct 9, 2014 at 4:41 AM, Rafa Haro <rharo@apache.org> wrote:
>
> > Hi Karl,
> >
> > That list of issues makes completely sense for a 1.8 version. I=E2=80=
=99m then
> > confuse on the development process for maintaining two branches, 1.8-de=
v
> > and 2.0. For example, for contributing the Alfresco Webscript connector
> I
> > implemented two versions because of the changes from 1.7 to trunk. Is
> the
> > plan to do the same for the issues in that list when necessary?
> >
> > Thanks,
> > Rafa
> >
> > En 9 de octubre de 2014 en 10:33:53, Karl Wright (daddywri@gmail.com)
> > escrito:
> >
> > Hi Rafa,
> >
> > Have a look at
> > https://svn.apache.org/repos/asf/manifoldcf/branches/dev_1x/CHANGES.txt
> > for
> > the current list. I've just created a JIRA 1.8 version too, but haven't
> > updated the tickets yet to include proper "fix in" values for the issue=
s
> > listed in CHANGES.txt.
> >
> > Karl
> >
> >
> > On Thu, Oct 9, 2014 at 4:30 AM, Rafa Haro <rharo@apache.org> wrote:
> >
> > > Hi Karl,
> > >
> > > What is supposed to be included in a reputed version 1.8?
> > >
> > > Thanks,
> > > Rafa
> > >
> > > En 9 de octubre de 2014 en 10:20:45, Karl Wright (daddywri@gmail.com)
> > > escrito:
> > >
> > > As you may recall, at the end of the 1.7 release cycle, there was a
> show
> > of
> > > hands as to whether 2.0 should be the next ManifoldCF release, and
> > whether
> > > that should break backwards compatibility. There were only positive
> > > comments for that plan, so that is what we adopted.
> > >
> > > It's come to my attention that there are some folks in the community
> that
> > > were unaware of that discussion, or are having some second thoughts.
> Just
> > > to be clear on the release policy as it currently stands, here it is:
> > >
> > > (1) ManifoldCF 2.x development is currently taking place on trunk.
> > > ManifoldCF 1.x development is taking place on branches/dev_1x.
> > >
> > > (2) There is a 2.0 release scheduled for December 31, 2014.
> Heretofore, I
> > > had not scheduled a 1.8 release, but we may decide to do that release
> in
> > > the same time frame as well.
> > >
> > > (3) All ManifoldCF 1.x future releases will remain backwards
> compatible
> > > with all earlier versions of ManifoldCF. ManifoldCF 1.7, for instance=
,
> is
> > > (supposedly) completely backwards compatible with 1.6, 1.5, etc.
> > >
> > > (4) ManifoldCF 2.0 is NOT backwards-compatible with 1.x. Future 2.x
> > > releases, though, will be backwards-compatible with 2.0 etc.
> > >
> > > I see no reason why we would stop supporting ManifoldCF 1.x at this
> time;
> > > indeed, I would expect there to be further releases of the 1.x branch
> for
> > > maybe even a year or more. The upgrade strategy I would recommend is
> as
> > > follows:
> > >
> > > (1) New users should go with MCF 2.0 (after it has been released).
> > > (2) Existing users should consider upgrading to MCF 2.0 ONLY if they
> > have a
> > > good reason to do so, such as new functionality that is only present
> in
> > > 2.x. Eventually, we will stop developing 1.x, but that's quite some
> time
> > > in the future.
> > >
> > > During the MCF 2.0 development cycle, I've been trying to make sure
> that
> > > the dev_1x branch includes all important changes that don't rely on
> MCF
> > > 2.0-specific constructions. So the next dev_1x release will be quite
> > rich,
> > > as well as remaining backwards compatible. If you have specific 2.0
> > > features that you think may _not_ have made it to 1.x, please post
> about
> > > it.
> > >
> > >
> > > Also, when should we release MCF 1.8? I think releasing at about the
> same
> > > time as MCF 2.0 makes the most sense, but will be a lot of release
> work.
> > > Thoughts?
> > >
> > > Karl
> > >
> >
>
>

--20cf303ea6a69932380504fc151e--