You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@manifoldcf.apache.org by Karl Wright <da...@gmail.com> on 2014/10/09 10:20:17 UTC
Compatibility between 1.x and 2.0, and release plans going forward
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
Re: Compatibility between 1.x and 2.0, and release plans going forward
Posted by Karl Wright <da...@gmail.com>.
I should also mention that, so far, we've managed to make it the case that
connectors developed for MCF 2.0 will also work unchanged on MCF 1.7 or
later (but, not the other way). We'll try to maintain this relationship
for as long as possible, but I am not yet confortable with giving a
guarantee of it.
Thanks,
Karl
On Thu, Oct 9, 2014 at 4:20 AM, Karl Wright <da...@gmail.com> wrote:
> 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
>
>
Re: Compatibility between 1.x and 2.0, and release plans going forward
Posted by Aeham Abushwashi <ae...@exonar.com>.
Thanks Karl.
On 13 October 2014 12:04, Karl Wright <da...@gmail.com> wrote:
> Hi Aeham,
>
> The whole point of 2.0 was to allow us to REMOVE duplicate and deprecated
> functionality. We really can't go back on that, I'm afraid, or there would
> be no point in having the 2.0 release in the first place.
>
> As I said, the schema modifications are minor, but you would have to
> rebuild the version strings of all documents in the ingeststatus table to
> perform a real upgrade. So this is not likely to be possible, unless
> someone writes special connector-specific code to do this.
>
> Karl
>
> On Mon, Oct 13, 2014 at 6:59 AM, Aeham Abushwashi <
> aeham.abushwashi@exonar.com> wrote:
>
> > Thanks for the quick response.
> >
> > Hand upgrading configuration tables could be an option for us, but my
> > biggest concern is the upgrade (or lack of) for the big tables, namely
> > jobqueue and ingeststatus. If that requires our customers re-ingesting
> > everything that had been previously crawled, we'd have a problem.
> >
> > This is not an pressing issue because we have no immediate plans to move
> to
> > 2.0 but an item for our med-to-long term roadmap.
> >
> > Regards,
> > Aeham
> >
> > On 13 October 2014 11:16, Karl Wright <da...@gmail.com> wrote:
> >
> > > Hi Aeham,
> > >
> > > My suggestion to you is to stay on 1.x. Upgrade to 1.7.1, and to 1.8
> > when
> > > it is released. We've committed to supporting 1.x for as long as
> > > necessary.
> > >
> > > The schema will indeed change, and will not change in a manner where a
> > > straightforward upgrade is possible, because (for example) the Forced
> > > Metadata built in tab goes away entirely, as does the corresponding
> > column
> > > in the IngestStatus table. In some circumstances, a hand upgrade might
> > be
> > > possible, but in other cases you will probably not be able to do it,
> > > because the contents of the fields would need to be altered in a
> > > non-obvious manner.
> > >
> > > Thanks,
> > > Karl
> > >
> > >
> > >
> > >
> > > On Mon, Oct 13, 2014 at 5:10 AM, Aeham Abushwashi <
> > > aeham.abushwashi@exonar.com> wrote:
> > >
> > > > Thanks Karl,
> > > >
> > > > What are your plans regarding database schema compatibility? If I
> have
> > > 10s
> > > > of millions of items already ingested and recorded in PostgreSQL (MCF
> > > > 1.6.x), what would my 2.0 upgrade options be:
> > > > 1. Database schema remains intact and existing crawls continue
> running
> > > > 2. Perform a schema upgrade using a supplied script before crawls can
> > > > continue
> > > > 3. Entire data set has to be re-ingested
> > > > 4. Other?
> > > >
> > > > Regards,
> > > > Aeham
> > > >
> > > > On 9 October 2014 09:20, Karl Wright <da...@gmail.com> wrote:
> > > >
> > > > > 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
> > > > >
> > > >
> > >
> >
>
Re: Compatibility between 1.x and 2.0, and release plans going forward
Posted by Karl Wright <da...@gmail.com>.
Hi Aeham,
The whole point of 2.0 was to allow us to REMOVE duplicate and deprecated
functionality. We really can't go back on that, I'm afraid, or there would
be no point in having the 2.0 release in the first place.
As I said, the schema modifications are minor, but you would have to
rebuild the version strings of all documents in the ingeststatus table to
perform a real upgrade. So this is not likely to be possible, unless
someone writes special connector-specific code to do this.
Karl
On Mon, Oct 13, 2014 at 6:59 AM, Aeham Abushwashi <
aeham.abushwashi@exonar.com> wrote:
> Thanks for the quick response.
>
> Hand upgrading configuration tables could be an option for us, but my
> biggest concern is the upgrade (or lack of) for the big tables, namely
> jobqueue and ingeststatus. If that requires our customers re-ingesting
> everything that had been previously crawled, we'd have a problem.
>
> This is not an pressing issue because we have no immediate plans to move to
> 2.0 but an item for our med-to-long term roadmap.
>
> Regards,
> Aeham
>
> On 13 October 2014 11:16, Karl Wright <da...@gmail.com> wrote:
>
> > Hi Aeham,
> >
> > My suggestion to you is to stay on 1.x. Upgrade to 1.7.1, and to 1.8
> when
> > it is released. We've committed to supporting 1.x for as long as
> > necessary.
> >
> > The schema will indeed change, and will not change in a manner where a
> > straightforward upgrade is possible, because (for example) the Forced
> > Metadata built in tab goes away entirely, as does the corresponding
> column
> > in the IngestStatus table. In some circumstances, a hand upgrade might
> be
> > possible, but in other cases you will probably not be able to do it,
> > because the contents of the fields would need to be altered in a
> > non-obvious manner.
> >
> > Thanks,
> > Karl
> >
> >
> >
> >
> > On Mon, Oct 13, 2014 at 5:10 AM, Aeham Abushwashi <
> > aeham.abushwashi@exonar.com> wrote:
> >
> > > Thanks Karl,
> > >
> > > What are your plans regarding database schema compatibility? If I have
> > 10s
> > > of millions of items already ingested and recorded in PostgreSQL (MCF
> > > 1.6.x), what would my 2.0 upgrade options be:
> > > 1. Database schema remains intact and existing crawls continue running
> > > 2. Perform a schema upgrade using a supplied script before crawls can
> > > continue
> > > 3. Entire data set has to be re-ingested
> > > 4. Other?
> > >
> > > Regards,
> > > Aeham
> > >
> > > On 9 October 2014 09:20, Karl Wright <da...@gmail.com> wrote:
> > >
> > > > 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
> > > >
> > >
> >
>
Re: Compatibility between 1.x and 2.0, and release plans going forward
Posted by Aeham Abushwashi <ae...@exonar.com>.
Thanks for the quick response.
Hand upgrading configuration tables could be an option for us, but my
biggest concern is the upgrade (or lack of) for the big tables, namely
jobqueue and ingeststatus. If that requires our customers re-ingesting
everything that had been previously crawled, we'd have a problem.
This is not an pressing issue because we have no immediate plans to move to
2.0 but an item for our med-to-long term roadmap.
Regards,
Aeham
On 13 October 2014 11:16, Karl Wright <da...@gmail.com> wrote:
> Hi Aeham,
>
> My suggestion to you is to stay on 1.x. Upgrade to 1.7.1, and to 1.8 when
> it is released. We've committed to supporting 1.x for as long as
> necessary.
>
> The schema will indeed change, and will not change in a manner where a
> straightforward upgrade is possible, because (for example) the Forced
> Metadata built in tab goes away entirely, as does the corresponding column
> in the IngestStatus table. In some circumstances, a hand upgrade might be
> possible, but in other cases you will probably not be able to do it,
> because the contents of the fields would need to be altered in a
> non-obvious manner.
>
> Thanks,
> Karl
>
>
>
>
> On Mon, Oct 13, 2014 at 5:10 AM, Aeham Abushwashi <
> aeham.abushwashi@exonar.com> wrote:
>
> > Thanks Karl,
> >
> > What are your plans regarding database schema compatibility? If I have
> 10s
> > of millions of items already ingested and recorded in PostgreSQL (MCF
> > 1.6.x), what would my 2.0 upgrade options be:
> > 1. Database schema remains intact and existing crawls continue running
> > 2. Perform a schema upgrade using a supplied script before crawls can
> > continue
> > 3. Entire data set has to be re-ingested
> > 4. Other?
> >
> > Regards,
> > Aeham
> >
> > On 9 October 2014 09:20, Karl Wright <da...@gmail.com> wrote:
> >
> > > 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
> > >
> >
>
Re: Compatibility between 1.x and 2.0, and release plans going forward
Posted by Karl Wright <da...@gmail.com>.
Hi Aeham,
My suggestion to you is to stay on 1.x. Upgrade to 1.7.1, and to 1.8 when
it is released. We've committed to supporting 1.x for as long as necessary.
The schema will indeed change, and will not change in a manner where a
straightforward upgrade is possible, because (for example) the Forced
Metadata built in tab goes away entirely, as does the corresponding column
in the IngestStatus table. In some circumstances, a hand upgrade might be
possible, but in other cases you will probably not be able to do it,
because the contents of the fields would need to be altered in a
non-obvious manner.
Thanks,
Karl
On Mon, Oct 13, 2014 at 5:10 AM, Aeham Abushwashi <
aeham.abushwashi@exonar.com> wrote:
> Thanks Karl,
>
> What are your plans regarding database schema compatibility? If I have 10s
> of millions of items already ingested and recorded in PostgreSQL (MCF
> 1.6.x), what would my 2.0 upgrade options be:
> 1. Database schema remains intact and existing crawls continue running
> 2. Perform a schema upgrade using a supplied script before crawls can
> continue
> 3. Entire data set has to be re-ingested
> 4. Other?
>
> Regards,
> Aeham
>
> On 9 October 2014 09:20, Karl Wright <da...@gmail.com> wrote:
>
> > 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
> >
>
Re: Compatibility between 1.x and 2.0, and release plans going forward
Posted by Aeham Abushwashi <ae...@exonar.com>.
Thanks Karl,
What are your plans regarding database schema compatibility? If I have 10s
of millions of items already ingested and recorded in PostgreSQL (MCF
1.6.x), what would my 2.0 upgrade options be:
1. Database schema remains intact and existing crawls continue running
2. Perform a schema upgrade using a supplied script before crawls can
continue
3. Entire data set has to be re-ingested
4. Other?
Regards,
Aeham
On 9 October 2014 09:20, Karl Wright <da...@gmail.com> wrote:
> 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
>
Re: Compatibility between 1.x and 2.0, and release plans going forward
Posted by Karl Wright <da...@gmail.com>.
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 <rh...@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 list
> 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 spent
> 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 then
> 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 this
> 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 <rh...@apache.org> wrote:
>
> > Hi Karl,
> >
> > That list of issues makes completely sense for a 1.8 version. I’m then
> > confuse on the development process for maintaining two branches, 1.8-dev
> > 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 issues
> > listed in CHANGES.txt.
> >
> > Karl
> >
> >
> > On Thu, Oct 9, 2014 at 4:30 AM, Rafa Haro <rh...@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
> > >
> >
>
>
Re: Compatibility between 1.x and 2.0, and release plans going
forward
Posted by Rafa Haro <rh...@apache.org>.
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 list 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 spent 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 then
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 this
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 <rh...@apache.org> wrote:
> Hi Karl,
>
> That list of issues makes completely sense for a 1.8 version. I’m then
> confuse on the development process for maintaining two branches, 1.8-dev
> 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 issues
> listed in CHANGES.txt.
>
> Karl
>
>
> On Thu, Oct 9, 2014 at 4:30 AM, Rafa Haro <rh...@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
> >
>
Re: Compatibility between 1.x and 2.0, and release plans going forward
Posted by Karl Wright <da...@gmail.com>.
Hi Rafa,
I committed the MCF 2.0 version of the connector you contributed, and then
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 this
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 <rh...@apache.org> wrote:
> Hi Karl,
>
> That list of issues makes completely sense for a 1.8 version. I’m then
> confuse on the development process for maintaining two branches, 1.8-dev
> 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 issues
> listed in CHANGES.txt.
>
> Karl
>
>
> On Thu, Oct 9, 2014 at 4:30 AM, Rafa Haro <rh...@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
> >
>
Re: Compatibility between 1.x and 2.0, and release plans going
forward
Posted by Rafa Haro <rh...@apache.org>.
Hi Karl,
That list of issues makes completely sense for a 1.8 version. I’m then confuse on the development process for maintaining two branches, 1.8-dev 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 issues
listed in CHANGES.txt.
Karl
On Thu, Oct 9, 2014 at 4:30 AM, Rafa Haro <rh...@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
>
Re: Compatibility between 1.x and 2.0, and release plans going forward
Posted by Karl Wright <da...@gmail.com>.
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 issues
listed in CHANGES.txt.
Karl
On Thu, Oct 9, 2014 at 4:30 AM, Rafa Haro <rh...@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
>
Re: Compatibility between 1.x and 2.0, and release plans going
forward
Posted by Rafa Haro <rh...@apache.org>.
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