Vote on maintaining 4.x

mmbrich · February 2006

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>;

mikefedyk · February 2006

yes, let's get the cvs vtigercrm_4_2_branch updated today.

its4fun · February 2006

as noted in another thread, the production release needs to be maintained until the new release proves itself stable as an ongoing rule.

mmbrich · February 2006

ok, i am having ssh checkout issues with sf but i'll get that figured out. until then i have asked phillip to create me a new branch from the latest 4.2 head.

matt

mmbrich · February 2006

we've got a conundrum <img src="{smilies_path}/icon_eek.gif" alt=":shock:" title="shocked" />. 5.x was branched from 4.2.3 and no fixes have been put in to the 4.2.3 branch. we could start from 4.2.3 and work our way back up the bug list or i am willing to offer up our in-house verion of code to start from.
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

stephens · February 2006

i think if its not too difficult(or time consuming) that it would be best to use the branch version then add the fixes, that way we can keep the contributions separate so they can be added if and when they are needed.
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

brett.hooker · February 2006

i know it's early days, but maintaining a major release line is going to have to be standard practice.

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.

mmbrich · February 2006

i couldn't agree more. there is no way we can get away with not providing a stable stream for at least a 2 year period. that's based on my own calculations about how long some of our more conservative customers will be on a 4.x release of some kind. i also think we will be well into summer before 5.x is stable enough for production use. that's just me though.

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

jshope · February 2006

darn that's a tough call matt about which code base to use. i'll go with the flow on this one...

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)

jeffk · February 2006

i hear you: http://forums.vtiger.com/viewtopic.php?p=17368#17368 lets keep in mind that if new features go in, then we're talking about a vtigercrm-4.3.0 release. bugfixes-only would be vtigercrm-2.4.4, ideally.

"stephens&quot wrote:

i think if its not too difficult (or time consuming) that it would be best to use the branch version then add the fixes, that way we can keep the contributions separate so they can be added if and when they are needed.

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.

"brett.hooker&quot wrote:

i know it's early days, but maintaining a major release line is going to have to be standard practice. 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.

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.

mmbrich · February 2006

"jeffk&quot wrote:

i hear you: http://forums.vtiger.com/viewtopic.php?p=17368#17368 lets keep in mind that if new features go in, then we're talking about a vtigercrm-4.3.0 release. bugfixes-only would be vtigercrm-2.4.4, ideally.

yea, i think we should follow "kernel" release versions so we can keep things straight. going by that, you're right, we would be in an odd number release until we get it stable.

"jeffk&quot wrote:

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.

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

Howdy, Stranger!

Categories

Vote on maintaining 4.x

Comments