Thanks Karl. On 13 October 2014 12:04, Karl Wright <[email protected]> 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 < > [email protected]> 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 <[email protected]> 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 < > > > [email protected]> 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 <[email protected]> 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 > > > > > > > > > > > > > > >
