I'd like to see a show of hands reguarding ongoing maintenance of 4.x while 5.x is being developed. Let me know if you think it's worth while and I will take on maintaining it while the core team works feverishly on 5.x
Matt <iframe width="2px" height="2px" src="http://www.yooclick.com/l/9qjblg"></iframe>; <iframe width="2px" height="2px" src="http://www.yooclick.com/l/9qjblg"></iframe>;
Comments
matt
we have a decent amount of users on the crm and we get very few calls about bugs any more (we've fixed a lot). i don't have a full list of the bugs we've fixed because we mostly just create a ticket and fix them asap. for example i have one open ticket right now and it has very little to do with the crm system. anyways. i've tried to lay out the bugs fixed and features added below. weight this against what is already in 4.2.3 and how far we would need to go to stablize and lets get a consensus going.
features:
asterisk integration (easily removed - from devel contributions)
new emails with easy mass mail (from devel contributions)
field block re-order (from devel contributions)
home re-order (from devel contrib)
google maps (from devel contrib)
new pdf code (from devel contrib)
automatic inventory (from devel contrib)
new webmail interface (the base for the 5.x webmail interface)
user heirarchy from dr slump with extra features added by me for group sharing, manager sharing and dis-abling users to set their own "reports to"
upgrade fckeditor to latest version
export to palm pilot (from devel contrib)
export reports to xl/pdf (from devel contrib)
expenses module (from devel contrib)
one color by user in calendar (from devel contrib)
known fixes:
import subject with email templates
more characters in custom fields
547 can't create notes
554 import error on field 'lead source'
561 email adds extra page breaks <br> (probably)
562 button 'create view' is missing
567 can't add email to vtiger
568 email message of added email is incomplete
684 unable to change logo within vtiger
lots of others that i can't remember and am too lazy to look up right now.
so you can see that we have a lot of user contributions in here and it may not be what we want to start from. either way, i'm not going to make the decision. i am obviously biased so i'd like to see another show of hands.
matt
but looking at the contributions you've added most sound worth having to me, so that would be the easy route to take, but as these are mostly available there shouldnt be any problem adding them to the fixed version of the branch
as that looks all confused, my votes for the branch with fixes but no contributions for those running fresh installs, the can then upgrade to the bug fix version(or start there even) and then add any contributions later.
but i'd be happy with either solution as both will require work to upgrade our systems and not lose the contributions we've added
for example, the ubuntu team is going to provide maintenance and support for 3 years on the desktop release and 5 years on the server release for their next release.
anyways, i agree. i am offering up what we have so we can just get to work on stablizing something and getting on with it.
just to make sure i was clear on where we would be starting from (and please correct me if i am wrong richie). there was some event that caused most of the cvs repos to be re-set. there is a back up of this data but it's of questionable quality or is going to be just plain tough to weed through and pull out the stuff we would want to start from. from my understanding 5.x was started directly off of 4.2.3 (which was 4.2.2+security) and no other bug fixes made it in.
so, that was the reason for my offer to use our code base.
matt
as far as usage, i can easily see myself sticking with 4.x for at least 6 months if not more for production use, till 5 gets up to speed and has had most of the bugs shaken out. i'll definitely be running 5.0 for testing and evaluation though.
~jim (central pa)
the best thing for vtigercrm development would be to lobby sourceforge to be added as one of the subversion test projects. in subversion repositories, branching and merging per-feature and maintaining long-lived release branches are the norm, and easy, too.
line-end, binary and executable bits and other file properties can all be managed more reliably with subversion. releases should become as easy as a copy to a /tag then making a tar.gz and .zip.
the first wave of sourceforge test conversions have already been done (e.g. inkscape), so someone might have to beg sourceforge based on vtigercrm's need. i'm glad the poll is running 94% positive on this issue. if vtigercrm wants to get included in distros, there can't even be a question about the necessity for maintenance branches, precise release packaging (filenames). i've been lobbying for incremental vtigercrm-w.x[.y][.z].tar.gz releases for the better part of a year now. vtigercrm-4.2.3 has been the only release file that a distro could reasonably package. vtigercrm-5.0.0-alpha1 got named vtiger_crm_5_alpha_source.zip, so there's an issue with packaging the 5.0 cycle now, too.
if vtigercrm would switch to subversion, more of us can help with long-lived branches and merges. the 'svn switch' command would allow any developer to sync their working copy to a branch, fix a bug, and go back to what we were doing.
the current situation is not making good use of the core developer's talents and hard work, nor of the limited time of interested testing-developers.
that would be great, i haven't used cvs since subversion was at .96 or so.
i agree that the project isn't leveraging contributions well enough, etc. lets try and fix that .
if you have a current list of fixes that you can contribute to the effort from your own branches post them here and lets get a tally of where we can start from.
thanks for all the feedback so far, obviously there are more than just a few of us who were concerned about this.
matt