Next release date of PhpGedView?

Hi all,

I am wanting to start a fresh geneology project.
I see that there has been a considerable subversion activity.

If there a next release coming out soon, then I can probably wait some time.

Or, Maybe I can continue with starting with 4.2.3 …
does any of you think that there could be any possible issues in upgrading 4.2.3 to future release (whenever its released)?

The last release of phpGedView was 4.2.3, on 2009-12-26.  Releases typically happen 3 times a year, and upgrading from one to the next is pretty easy.  Typically, you just need to upload the new files to the server.

However, development has slowed recently as many of the active developers left phpGedView to start a new project (webtrees), so I expect the next release will not be soon.  None of the subversion changes since 4.2.3 are significant enough to warrant a release - just minor maintenance and bug fixes.

As an indication of activity, webtrees split from phpGedView at subversion revision #6937.  phpGedView is now at #6958 while webtrees is now at #8034.  Nightly builds of webtrees are available (webtrees.net).  We're making some major changes to the underlying infrastructure, so until these are finished, the code isn't really suitable for use on a live/production site.

Shobhit

While Greg refers to minor bug fixes since the release of 4.2.3, others would argue that there are significant improvements contained therein. And, as the current SVN condition, #6937, is VERY stable, I would recommend simply doing a tarball download of the SVN code at that SVN level and use it to install PGV, instead of 4.2.3. The procedure would be identical to the WIKI install instructions, and you'll have a quite pleasant and usable code structure for your new site.

Also, I don't want it to appear that Greg was soliciting you to 'switch' to webtrees. In fact, IMHO, the project is no where near ready for casual, new, or in many cases, even experienced admins to begin installing it: GREG says:

the code isn't really suitable for use on a live/production site.

We wholeheartedly agree. Just yesterday, the code added tables that made a complete database deletion and reinstall necessary. It is likely that this will happen again, as the code is, at best, in a beta condition.

Go ahead and install PGV, get accustomed to using it and begin your ancestral journey. When there is a new release for PGV, you will be notified here. webtrees version 1 will most likely be ready for public consumption by August 2010 and will provide a method for moving from PGV, so don't rush into anything drastic just yet.
_Stephen

Thanks a lot for your detailed responses. I didn't even know about webtrees. If the developers of PGV are working on it, then I am sure it will come out very good.

I will start with PGV for now. Hoping to use webtrees next year.

Thanks to all, will come back if I encounter any issues.

I just saw these websites:
http://www.genoom.com/
http://www.geni.com/

They ofcourse are not open source, and are very limited.

But I wish that it would be great if Webtrees can borrow (whatever possible) good ideas from these websites.

Shobhit
Why would you not wish PGV tp  borrow these allegedly good ideas? Also, what do you think are these 'good' ideas. Most of the features present in those programs have been discussed here and, IIRC, I don't think there are many RFE's submitted for inclusion of anything present there but glaringly missing here. PGV is not a dead project.
Stephen

fisharebest has his own reasons for wanting to split from PGV. Some of this initiall changes make the webtrees code base totally useless for many of us so we will not be joining him ;)

I have my own port of PGV so as to get back cross database working which was lost when PDO was forced into the code base. Perhaps now is the time to request a roll back on that so we can restore to the original cross database capability - since the original proponents of that seem to have jumped ship ?

Lester,
I can't imagine, in any of my wildest dreams (nightmares), that the code would be rolled back. As all the changes are in SVN, you would be welcome, under GNU rules, to spin off a new project, based on pre-PDO introduced code, and begin development of database independent or dependent (your choice) code to provide a similar result. There are very few developers left here at this time, and its doubtful any would wish to tackle a project as mammoth as you propose. BTW, under Sun's direction and cooperation, it appears that work has again begun on further development of the PDO and PDO-MySQLND extensions.
-Stephen

Stephen - roll back is probably the wrong word. ADOdb simply replaces PDO and restores all of the SQL abstraction facilities needed for proper cross platform working. It's only a dozen or so files that are affected - except for the installer which is a major block because of ->

PDO-MySQL is about the only driver that actually works reasonably - because that has been defined as the lowest common denominator. Many of the other drivers simply can't be completed because you need to be able to map some of the key data types to get things working. TEXT is not the same thing as BLOB and CLOB, as far as PDO is concerned, But Oracle and Firebird use C/BLOB interchangeably with TEXT …. and there is no way to tell PDO NOT to use streams on a field by field basis.

Ideas from geni.com and the like?  Well, I think the drag-n-drop aspect would be a marvelous thing, especially if it could be made a bit more powerful than geni without losing intuitiveness and robustness.

I'm curious about the great desire for "cross-platform" DB interface when at least one of the DBs is available for all platforms.  Personally, I would rather give up a little portability for the chance to move certain parts of the logic into stored procedures and
functions in the DB.  Not only would that improve performance (I think it would anyway) but performance would be improved by the elimination of a multi-DB portability layer.  Instead of having to avoid all DB features not common, you'd be able to take advantage of those that the chosen DB uses.  (Like stored procedures!)

wgroleau - As someone who has been working with databases since the early 90's, I prefer to stick with what I have now some 20 years of experience on. YES using features like stored procedures would be nice, and using triggers built into the database would be nicer still. SO if you want to switch to a straight jacket, how about picking one that fully supports all of the higher level functionality ;) MySQL is simply not a reliable multi-user platform, so ANYTHING would be better than it. Personally I could probably live with Postgres if a single database had to be used for some reason … simply because I can port THAT SQL to Firebird easily!

<<MySQL is simply not a reliable multi-user platform, so ANYTHING would be better than it>>

You keep saying this.  Can you elaborate a bit?

MySQL runs the 7th most popular website on the net (wikipedia). Pretty much every major website uses it somewhere.  Even google uses it to run AdWords.  Seems pretty reliable to me.

<<MySQL runs the 7th most popular website on the net (wikipedia).>>
Google do not run a 'production' copy of MySQL, and certainly don't run anything heavy on it. Most of the heavy users such as Facebook have modified versions of MySQL and although they push fixes back into the project, it depends on which particular configuration of MySQL you are using as to how it benefits other users. Which database engine are you ACTUALLY using since MySQL has several options. The Wikipedia setup is certainly not the 'open source' version.

I have live data from local government sites going back 20 years. We have never had to 'recover' data, as has happen a number of times in the past even on wikipedia. So I have no intention of changing from a database that I trust!

<<MySQL is simply not a reliable multi-user platform>>

You still haven't said why.

Out of interest, which RDBMS do you consider reliable in a multi-user environment?

You should know by now that I am a long time Firebird/Interbase user ;) Since it was open sourced 10 years ago I've not even had to worry about licenses …

With regard MySQL stability - just check the MySQL lists …
I don't know if I am 'behind the times', but on a standard MySQL installation can you run a live backup yet? Certainly in the past one had to shut out other users. Firebird has various live backup options which sync my live sites to their various backups.

For what it's worth, I work for one the top 5 banks in the U.S.  Although MySQL is not one of our preferred DBMS' we do have it deployed in several mission critical environments including one that uses its replication capability.   All in all I find it to be as reliable as Oracle, UDB and SQLServer.

If you feel that Interbase is the "reliable database" you need, then why not put all the energy you're expending on a cross-platform interface into one optimized for Interbase?

wgroleau - Since I live in the real world, my council customers insist on Oracle or MSSQL so anything I work on must be cross database. Firebird will run the majority of Oracle SQL without any problems since Oracle was originally built at the same time as Interbase, so working with a free database offers the users a chance to drop the expensive stuff when they want to, and some already are!

PDO is as bad with Oracle and MSSQL as it is with Firebird, and ADOdb simply works out of the box. If you follow the discussions on the PDO development list - where I AM trying to improve things - then you will see that PDO has a long way to go, to do MOST things cross dataabse :(

One of the advantages of the way ADOdb works is that you CAN optimize the core for your own application, which is something I have already done.

I've kept out of the debate on the future of PGV, but you would have to think it is pretty bleak. Perhaps, in its current form, it had gone about 'as fur as she can go' without totally rebuilding some of the rusted on parts. The breakaway group have space (if not time) to rejig a lot of things, but, in time, their decisions today will prove no less restrictive in a few years' time. It just happens that way.

I've dismantled my PGV sites.  

Paul

Hi - as an interested but non expert user, it would be great to see some kind of systematic pro & con comparison between PGV and Webtrees, in terms of intended user experience as well as underlying philosophy.  If I understand correctly, PGV is the only stable game in town right now, but would be interested to see what long term trajectory differences are envisaged

Are we not being premature?
I've been here longer than almost any of you, and have been intimately involved in suggesting and assisting with testing and development of many of the features that have been added over the last six years. As this is a volunteer project, I have seen splinter groups before, as well as developers who simply ran out of spare time or lost interest in the project and left. Each of those that left to develop new software have had excellent reasons for doing so and some successfully, while others have been less so.

Regardless, PGV has previously muddled through these trying times and new faces and brains have emerged or joined, only to have the program make new leaps forward. I must reiterate, PGV is - at this time - a very stable piece of programming, perhaps more so than at any previous time, and its chock full of features that many admins and users don't even know about. (Just read the HELP forum if you doubt this.)  I think those that abandon it during this period of hiatus do themselves an injustice.

Yes, there is another pretender to the throne of best online genealogy program. It will, most likely, be ready in August, and it is quite impressive in both focus and operation. However, for some admins it may be too limiting in DB scope, resource demands or loss of features. IMHO, to predict the demise of PGV at this stage is inaccurate at this time. PGV could suffer along with little to no change for years, and it may well attract new developers, as it has during past lulls, who revitalize the project. Don't write it off yet.
-stephen

The enigma is that everyone is right - and wrong, all at the same time.

The underpinning scripts for PGV reflect some decisions made at the outset, and are now difficult to change. As an example, screen design code is scattered all over the place, and are a nightmare to change. So we have a rather awkward GUI, and little chance of improving it.

At the same time, software has moved along, and there are now better ways of doing things than before. Some genie software accepts this situation (the one built on MS Access, surely the world's worst bit of db s/w, is an example), have stuck with their 10 year old model, and tweaked it here and there. At times they must despair, but they have put their customers first, not their softies. It may be a single-file trek to hell, but that's their commercial decision, and they make it work.

The new branch will doubtless be a softies paradise for a time, but the arteries will be hardening already. As I said, that's the nature of things. And the complaints about the forum software, right here, will be replaced with oddities/dislikes about their new one.  

Meantime, I plan to care for my users - focusing on getting information as correct as I can without worrying about behind-the-scenes changes.   

Premature? Definitely not…  :-)

Paul

The current version of PGV works, so why not use it?

I'm still slowly improving my tree ad have yet to hit any problems that cause me grief. If I DO find a problem that I should be able to fix it, but I think that the current state of the code base means that creating a bug fix build may be difficult as work has been started that has not been completed. BUT any bug fixes can be made as an update against the last release.

A new build of PGV has probably been blocked because the people working on it have jumped ship. that is why I suggested that the code base is rolled back to the current release state so that thouse of use who are able to work on it can at least work from a finished code base ….

And SF needs to go back to it's previous forum editors … no need to bloody keep changing things just for changes sake.